Why C2PA Needs Policy-Based Governance

There is a moment in every content provenance project where the engineering stops being the hard part.

It usually arrives about two weeks in. Someone has pulled the open source C2PA SDK, wired it into a build step or an export hook, and produced a file with a valid manifest. The demo works. The validator agrees. And then somebody in the room asks who is going to hold the key, and the conversation changes character entirely.

That question has no SDK answer. Neither do the ones behind it.

What the toolkit hands back

A signing library does one thing well: it takes bytes and a key and produces a manifest that other tools can read. Everything required to run that as a service belongs to you the moment the demo ends.

Certificates have to be issued and renewed on a schedule nobody wants to own. Private keys need protection that survives an auditor, which in practice means hardware, which means custody, rotation and revocation. Access to signing needs authentication and authorisation, because a signing endpoint that anyone in the build system can call is a signing endpoint that will eventually sign something nobody intended. Conformance is a programme with technical and security evaluation attached, not a checkbox. And the specification keeps moving, so whatever you build has to keep pace with it or quietly fall off the trust list.

None of that is exotic. It is the ordinary cost of operating a security service, and it is the reason the industry has certificate authorities rather than each company minting its own roots. Certificate authorities are making this argument themselves now: the visible credential depends on invisible infrastructure, and the choice for most organisations is to build that infrastructure or adopt a platform that already runs it.

That framing is right, and it does not go far enough.

Operations is not the same as governance

Running a signing service well answers can we sign reliably and securely. It does not answer the questions a relying party actually asks when a file arrives.

Who inside this organisation was permitted to make this claim, about this class of artifact? Under which policy, and which version of it? With which credential — a staff identity, a contractor’s, a build system’s, an agent’s? Was the authority behind that credential delegated by someone who could delegate it, and has it since been withdrawn? And on the other side of the transaction: whose claims does my organisation accept, and for what? A wire service I trust for photographs is not automatically a source I trust for software packages.

Those are policy questions, and they have policy answers. They are also the questions that determine whether provenance is worth anything, because a signature that is cryptographically perfect and organisationally meaningless tells a recipient nothing they can act on.

The C2PA specification is deliberate about this. It defines how a claim is expressed, how bindings work, how a manifest is validated, and it runs a conformance programme with a trust list of recognised signers. It does not tell an organisation which of its people and systems may assert what, or which other organisations to believe. That was never its job. It is a format for exchange, and a format cannot decide institutional questions on your behalf.

What policy-based governance looks like

The useful version of this is not a document. It is policy the platform applies, at the moment work happens.

A policy describes a workflow that already runs — what is attested, at which step, by which identity, under which credential. It is set once and applied wherever that workflow executes, which is the difference between a rule and a rule that holds. When a contractor’s engagement ends, the authority behind their credential is withdrawn and every subsequent verification reflects it. When a specification changes, the record is written to the new version without anyone re-plumbing a pipeline.

Three things have to be governed together for that to work.

Identity. Every organisation, team, system and agent that touches an artifact needs an identity, and the certificates and hardware-held keys behind it. Anchored, in practice, in a certificate authority the industry already recognises — which is why we integrate natively with DigiCert rather than asking anyone to trust roots of our own.

Credentials. What each identity is allowed to claim: roles, memberships, certifications, delegated authority. Issued, renewed and revoked centrally, because authority granted per team is authority nobody can audit.

Trust. Whose claims an organisation accepts, expressed as a graph of who granted standing to whom, for which artifact classes, rather than inherited wholesale from a single list.

Miss any one of the three and the other two degrade. Identity without credentials tells you who signed but not what they were permitted to assert. Credentials without trust tell you what was claimed but not whether to believe the issuer. Trust without identity is a list of names.

The part nobody has solved yet

Here is where it gets interesting for publishing specifically.

Issuing a certificate to an organisation is a solved problem. Issuing one to every freelance photographer, stringer, agency editor and localisation vendor a newsroom works with is not — not because it is technically hard, but because the economics and the onboarding do not survive contact with a thousand contributors on short engagements. So today that entire population is unidentified, and the provenance record stops at the masthead.

A lighter class of credential fixes the mechanics. What it lacks is a certificate authority behind it, which is precisely why enterprises hesitate to depend on it. Anchor those credentials to roots the industry already trusts, govern them with policy that says who may assert what, and the gap closes — the record can name the contribution without the newsroom running a CA for its freelancers.

That is not a media problem alone. The same shape appears in software supply chains, where builds pass through systems and vendors that need identity and authority without each acquiring a certificate of their own, and in agent workloads, where the thing making the claim was instantiated ten minutes ago.

Where this lands

The industry has spent three years getting the format right, and it has largely succeeded. C2PA does what it set out to do.

The next three years are about the layer above it: who may attest, under what policy, whose attestations you accept, and how any of that is proven a year later when someone asks. That layer is governance, it is policy-based, and it is the difference between a signed file and a record an organisation can stand on.

The SDK was never going to give you that. It was never supposed to.