Extraction & Trust

Provenance Chain & Trust Tiers

Classifying sources: hardware cameras, AI generators, software editors.

The previous sections explained how Apertrue extracts a C2PA manifest and verifies its hash chain. But a verified manifest only proves that some signer signed some content. It doesn't answer the harder question: how much should you trust this signer?

A Leica camera with a hardware-embedded signing key is fundamentally different from a copy of Photoshop that anyone can download. An AI generator that honestly declares its output is different from software that strips provenance to launder a deepfake. Apertrue classifies every signer into one of four trust tiers, and traces the provenance chain back to the original capture to determine which tier applies.

Trust tiers

Every piece of content that enters Apertrue is assigned a trust tier based on who signed it and where it came from:

TierNameWhat it meansExample signers
1Hardware-attestedSigned by a device with a hardware-embedded key that cannot be extracted. Highest trust — the image was captured by a real camera sensor.Leica M11-P, Sony Alpha, Nikon Z9, Google Pixel, Samsung Galaxy
2AI generatorSigned by a declared AI content generator. The signer honestly labels its output as synthetic. Trusted as authentic AI disclosure.OpenAI DALL-E, Midjourney, Adobe Firefly, Stability AI, Google Imagen
3Software with chainSigned by editing software, but the ingredient chain traces back to a Tier 1 or Tier 2 origin. The edit history is preserved and verifiable.Adobe Photoshop (editing a Leica photo), Lightroom, Capture One
4Software-onlySigned by software with no ingredient chain to a trusted origin. Cannot verify where the content came from. BLOCKED — proof generation is refused.Any software signer without ingredients
Key Insight
Tier 4 content is blocked before a proof is ever generated. The ZK circuit only accepts tiers 1, 2, and 3. This is the anti-laundering gate — you cannot take a deepfake, sign it with arbitrary software, and get it verified on Apertrue.

Signer classification

When Apertrue extracts a C2PA manifest, the first step is identifying who signed it. The signer name comes from the certificate chain — specifically the issuer field of the signing certificate, falling back to the claim_generator field in the manifest.

The classifier checks the signer name against known patterns:

  1. Hardware signers. Matched against known camera manufacturers: Leica, Sony, Nikon, Canon, Fujifilm, Google Pixel, Samsung Galaxy, Huawei, Olympus, Panasonic, Pentax, Hasselblad, Phase One. These devices have tamper-resistant signing keys embedded in hardware — the private key never leaves the device.
  2. AI generators. Matched against known AI content platforms: OpenAI, DALL-E, Midjourney, Stability AI, Stable Diffusion, Adobe Firefly, Google Imagen, Meta AI, Anthropic, Sora. These signers honestly declare their output as AI-generated via C2PA action assertions.
  3. Software (default). Everything else — Photoshop, Lightroom, Capture One, GIMP, ProofMode, Truepic, and any other software signer. Software signers are not inherently untrusted, but their trust depends entirely on their ingredient chain.

Classification happens on the first match across the signer name, claim generator, and software agent fields. A JPEG from a Leica camera edited in Photoshop will have Photoshop as the top-level signer (software) but a Leica ingredient manifest (hardware) — resulting in Tier 3 after chain walking.

The provenance chain

C2PA supports ingredient manifests — when software edits an image, it can embed the original image's manifest as an ingredient in the new manifest. This creates a chain: the edited image references the original, which may reference an even earlier version.

Three linked manifests. Leica M11-P (Tier 1, hardware) captures the original image. Adobe Lightroom (software) shows ingredient relationship from Leica, crops and adjusts. Adobe Photoshop (software, top-level signer) shows ingredient from Lightroom, adds text overlay. Final classification: Tier 3 (software with unbroken chain to Tier 1 origin).

Apertrue walks this chain recursively using a depth-first algorithm:

Chain walking algorithm (simplified)
walkChain(manifests, currentLabel, depth):
  // Guard against infinite loops or extremely deep chains
  if depth > MAX_CHAIN_DEPTH (10):
    set chainTruncated = true
    return null

  manifest = manifests[currentLabel]
  signerType = classifySigner(manifest.signerName)

  // Find and recurse into ingredient manifests
  bestIngredientTier = null
  for each ingredient in manifest.ingredients:
    if ingredient has a manifest reference:
      tier = walkChain(manifests, ingredient.manifestLabel, depth + 1)
      if tier is better (lower number) than bestIngredientTier:
        bestIngredientTier = tier

  // Determine this step's trust tier
  return determineTrustTier(signerType, hasIngredients, bestIngredientTier)

Tier assignment rules

The determineTrustTier function applies straightforward rules:

  • If the signer is hardware → Tier 1. Always. Hardware attestation is the highest trust regardless of ingredients.
  • If the signer is an AI generator → Tier 2. The content is honestly declared as synthetic.
  • If the signer is software and the ingredient chain reaches a Tier 1 or Tier 2 origin → Tier 3. The edit history is intact and verifiable.
  • If the signer is software and the ingredient chain reaches another Tier 3 origin → still Tier 3. A chain of software edits preserves trust as long as the original origin is trusted.
  • If the signer is software with no ingredients or a broken chain → Tier 4. Blocked.

Multiple ingredient tie-breaking

A manifest can have multiple ingredients — for example, a composite image made from several source photos. When multiple ingredient chains exist, Apertrue keeps the most trusted (lowest tier number) origin. If one ingredient traces back to a Leica (Tier 1) and another to unknown software (Tier 4), the composite is classified as Tier 3 — the trusted chain is what matters.

Anti-laundering

The trust tier system is Apertrue's primary defence against content laundering — the practice of taking unverified or manipulated content and making it appear verified. Without trust tiers, an attacker could:

  1. Generate a deepfake with no C2PA manifest.
  2. Open it in any C2PA-capable software (which creates a new manifest).
  3. Upload it to Apertrue with a valid C2PA signature.

The trust tier system blocks this at step 3. The software-signed image has no ingredient chain — it's Tier 4, and Apertrue refuses to generate a proof. The attacker would need to forge a hardware camera's signing key (stored in tamper-resistant hardware) or compromise an AI generator's certificate to bypass this.

Important
Tier 4 blocking is enforced before the ZK circuit runs. The client-side extractor determines the trust tier during manifest parsing. If the content is Tier 4, the upload flow shows the file as blocked with an explanation — no computational resources are wasted on proof generation.

Blocking reasons

When content is blocked, the user sees a specific reason:

  • No valid provenance chain found — the manifest has no ingredient references at all.
  • Broken provenance chain — ingredients are referenced but the chain is incomplete (missing manifests, truncated at depth limit).
  • Software-only signing with no ingredient chain to trusted origin — the chain exists but never reaches a hardware or AI generator signer. This is the classic laundering pattern.

Chain depth and safety

The chain walker enforces a maximum depth of 10. This prevents denial-of-service through deeply nested manifests and handles the practical reality that most legitimate chains are 2-4 steps deep (capture → one or two edits → export).

If the chain exceeds 10 levels, it's truncated and marked. A truncated chain where the deepest reached manifest is software-signed results in Tier 4 (blocked), because the origin cannot be verified. A truncated chain that reached a hardware or AI origin before truncation still gets the appropriate tier.

What the ZK circuit receives

After chain walking, the trust tier (1, 2, or 3) is passed to the ZK circuit as an input. The circuit treats it as a public output — anyone verifying the proof can see the trust tier. This means:

  • Viewers on Apertrue see "Hardware Verified" (Tier 1), "AI Generated" (Tier 2), or "Software Edited" (Tier 3) badges.
  • The backend stores the tier as a verification status (VerifiedCamera, VerifiedAi, or the software-with-chain equivalent).
  • The tier cannot be forged — it's committed to by the proof and verified by the circuit.

The trust tier is determined client-side during extraction and verified by the circuit's trust list membership check. The circuit doesn't re-walk the ingredient chain — it verifies that the signing certificate is a member of the trust list (covered in the next section) and that the claimed tier is consistent with the certificate's classification.

Backend handling

After the ZK proof is verified, the backend stores the provenance chain as a JSON blob alongside the media record. The full chain (every step from origin to final edit) is preserved for transparency, but the backend does not re-validate the tier — the ZK proof is the source of truth.

The verification status mapped from trust tiers:

Trust tierVerification statusUser-visible badge
Tier 1VerifiedCameraHardware verified — captured by a trusted camera
Tier 2VerifiedAiAI generated — declared synthetic content
Tier 3Verified (software)Edited — software-signed with chain to trusted origin
Tier 4BlockedNever reaches the backend

Content moderation screening happens before proof verification — the backend analyses the image bytes for policy violations before accepting any ZK proof. This means even Tier 1 hardware-verified content can be rejected if it violates content policies (covered in Content Moderation).

Note
The provenance chain is stored but not re-validated because the ZK proof already guarantees it. The backend trusts the math: if the proof verifies, the trust tier is correct, the certificate is in the trust list, and the hash chain is intact. There is nothing to re-check.

The next section explains how the trust list itself works — how certificates are organised into a Merkle tree, how membership is proven inside the circuit, and how the oracle keeps the list updated as new trusted signers are added.