Why C2PA Needs Policy-Based Governance

Two weeks into a content provenance project, the engineering is finished and the hard part begins.

Someone pulls the open source C2PA SDK, wires it into a build step or an export hook, and produces a file with a valid manifest. The demo works and the validator agrees. Then someone asks who holds the key.

The SDK has no answer to that question, and none to the questions 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 library as a service becomes the implementer’s problem 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 an implementation has to keep pace with it or fall off the trust list.

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

The argument is right. It also stops short.

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 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 worth trusting for photographs is not automatically a source worth trusting 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 the boundary. 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. A format for exchange cannot decide institutional questions on an organisation’s behalf.

What policy-based governance looks like

Policy-based governance 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 the workflow runs, so the rule is enforced rather than documented. When a contractor’s engagement ends, the authority behind their credential is withdrawn and every subsequent verification reflects the withdrawal. When the specification changes, provenance is written to the new version without anyone re-plumbing a pipeline.

Three things have to be governed together.

Identity. Every organisation, team, system and agent that touches an artifact needs an identity, with the certificates and hardware-held keys behind it, anchored in a certificate authority the industry already recognises.

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 names the signer but not what the signer was permitted to assert. Credentials without trust show what was claimed but not whether to believe the issuer. Trust without identity is a list of names.

The part nobody has solved yet

Publishing exposes the gap most sharply.

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 that entire population goes unidentified, and provenance stops at the masthead.

A lighter class of credential solves the onboarding: a newsroom can issue one to a freelancer in minutes. Enterprises hesitate to rely on those credentials because no certificate authority stands behind them. Anchor the credentials to roots the industry already trusts, govern them with policy that says who may assert what, and a newsroom can name the contributor without operating a certificate authority for its freelancers.

The gap is not confined to media. 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.

What comes next

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 belong to the layer above the format: who may attest, under which policy, whose attestations an organisation accepts, and how any of it is proven a year later when someone asks. That layer is governance, and governance is what separates a signed file from provenance an organisation can rely on.

The SDK was never going to provide it. It was never supposed to.