Test whether C2PA Content Credentials survive your CDN

The delivery gap

A signed source file is not evidence of the bytes users receive.

Content Credentials are bound to asset bytes. A resize, re-encode, metadata policy, or generated rendition can change what reaches the public URL. The source may still inspect cleanly while the delivered variant has no embedded manifest or no longer links back to the selected source.

The practical test target is therefore the exact delivery URL, not a screenshot, source-file assumption, or CMS setting. Repeat it for every format, crop, breakpoint, or cache variant that matters to the product.

A narrow technical boundary

Test the declaration without turning provenance into a truth verdict.

Article 50 does not require C2PA by name. If a team has chosen C2PA as one delivery control, this test can help verify the configured mechanics; it does not provide complete Article 50(2) marking or detection coverage. For disclosure testing, use the Article 50 CI guide.

Public released-version proof

Inspect the evidence before copying the configuration.

The controlled fixture uses a public test key and synthetic source-type data. The source and delivered images render the same test card. The delivered file adds an update manifest whose reachable ancestry contains the source label. The negative control removes the delivered PNG's C2PA caBX chunk and verifies that the remaining bytes equal the unsigned fixture.

Exact claim: for these exact bytes, released v0.3.0 observed embedded locally valid manifests and found the controlled source label in reachable delivered ancestry. The manifest-free control produced the two recorded failures. This public fixture simulates destructive delivery; it is not a claim about every CDN.

Two assets, one declaration

Compare the source with the final public URL.

Keep the known source file in the repository and point delivered at the exact URL people receive. Both sides are required for the chain comparison.

# .art50-ci.yml
version: 1

project:
  name: generated-media-delivery

output:
  directory: artifacts/art50
  screenshots: false

provenance:
  - id: delivery-image
    source: ./assets/source.png
    delivered: https://cdn.example.com/media/image.png
    requireManifest: true
    requireEmbedded: true
    requireSourceManifestInDeliveredChain: true
    failOnInvalid: true

Do not add expectedDigitalSourceType to this shared pair unless the exact URI must appear directly in both active manifests. v0.3.0 checks that field independently against every configured asset; it does not inherit a source value from delivered ancestry.

Manual baseline with c2patool

Before automating, download the exact delivered bytes and inspect them with the official Content Authenticity Initiative CLI. This establishes what the URL serves at that moment.

curl --fail --location   --output delivered.png   https://cdn.example.com/media/image.png

c2patool delivered.png

Manual inspection is useful for diagnosis. The CI check adds a declared source comparison, scheduled recurrence, structured failure codes, and retained JSON/HTML evidence.

Make delivery observable

Run on changes and against production every week.

# .github/workflows/c2pa-delivery.yml
name: C2PA delivery regression

on:
  pull_request:
  workflow_dispatch:
  schedule:
    - cron: "17 8 * * 1"

permissions:
  contents: read

jobs:
  provenance:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v6
      - uses: Rubiss/art50-ci@v0.4.0
        with:
          config: .art50-ci.yml
          output: artifacts/art50
          artifact-name: c2pa-delivery-evidence
          retention-days: "30"
          install-browser: "false"

The tagged composite Action supports GitHub-hosted Linux runners. A completed audit uploads the validated report directory before returning 0 for a pass or 1 for failed assertions. Configuration or execution errors return 2; an early error before report creation may produce no artifact.

Pull requests catch configuration and source changes. The scheduled run checks the production delivery path even when no repository change occurs. Each report remains a time-bound observation, so choose a cadence that matches delivery risk and evidence-retention policy.

Evidence, not a badge

Read the observations that produced PASS or FAIL.

• Target, resolved target, MIME type, byte count, observation time, and SHA-256 for each inspected asset
• Manifest presence, embedded state, active label, manifest labels, and reachable ancestry labels
• Local validation state, individual validation statuses, and directly observed action digital-source types
• Whether the source active label was observed in delivered ancestry and the exact structured failure codes
• Matching aggregate JSON, rendered HTML, and one privacy-minimised provenance summary per asset

Diagnose the failure code before changing the policy.

A failure is evidence about the inspected target, not a remediation instruction. Preserve the failing bundle first. Then reproduce against the downloaded bytes, change one delivery setting at a time, and rerun both the manual inspection and CI assertion. If a team deliberately changes source identity or provenance policy, review and update the declared expectation rather than weakening it merely to make the job green.

Production checklist

Test every delivery variant that can change the bytes.

• Use the final public URL, not the CMS preview or origin URL
• Cover important resize, crop, quality, format, and device variants separately
• Verify both warm and cold cache paths when the platform can produce different renditions
• Rerun after media-library, image-optimization, or CDN-policy changes
• Schedule production checks so delivery drift is detected without waiting for a code change
• Retain the report with the release and investigate the exact failure code before changing policy

Preservation is not universal. Cloudflare documents an explicit Content Credentials preservation setting; Cloudinary documents delivery-time provenance features; and image libraries such as sharp expose metadata-retention choices. Treat those settings as implementation inputs, then verify the resulting bytes.

Choose the path

Copy the proof for free or choose a monitored launch for delivery and accountability.

Result boundaries

Frequently asked questions

Primary technical sources

Start with the specifications and service documentation.

These sources describe C2PA binding and ingredient structures, validation concepts, manual tooling, and current delivery settings. They—not this guide—are authoritative for their respective systems.