You Shouldn't Need a Certificate Authority to Prove You're Real

Certificates cost money. You need a recognized Certificate Authority on the C2PA Trust List, and the infrastructure for smaller organizations is still maturing. This is a structural issue in how C2PA trust works today.

How C2PA Trust Works (And Where It Breaks)

C2PA uses X.509 certificates to establish identity. When you sign content, you’re attaching a certificate chain that traces back to a Certificate Authority on the C2PA Trust List. Verifiers check that chain. If it validates, the signature is trusted.

This works well for:

Large organizations with existing PKI infrastructure
Companies that can afford enterprise CA relationships
Regions with mature certificate ecosystems

It works less well for:

Independent creators and small studios
Organizations in emerging markets
Anyone who can’t justify $500-5,000/year for a code signing certificate
New entrants who need to prove authenticity before they have institutional credibility

The C2PA community knows this. There’s active work on making certificates more accessible — subsidized programs, simplified issuance, alternative validation methods. But ecosystem change is slow, and creators need to prove their work is authentic today.

The Trust List Problem

Beyond cost, there’s a philosophical issue: C2PA’s trust model is fundamentally a trust list.

A small number of Certificate Authorities are on the list. If your certificate chains to one of them, you’re trusted. If it doesn’t, you’re not. The list is curated by the C2PA steering committee — Adobe, Microsoft, Google, and other major players.

This creates a gatekeeping dynamic, even if unintentional:

Who decides which CAs are trustworthy?
What about regional CAs that serve specific markets?
What about organizations that are legitimate but don’t fit the CA model?

Trust lists work. They’re simple to verify. But they’re also centralized chokepoints in an ecosystem that claims to be about authenticity, not permission.

A Different Model: Trust Graphs

What if trust didn’t flow from a list, but from relationships?

That’s what we’ve built with the Decentralized Trust Overlay (DTO). Instead of asking “is this certificate on the approved list?”, we ask “does this identity have trust relationships I recognize?”

How it works:

Identity via DIDs: Organizations publish a Decentralized Identifier (DID) — a self-sovereign identity that doesn’t require a Certificate Authority to create.
Trust policies via trust.json: Each organization publishes a signed trust policy at /.well-known/trust.json declaring who they trust, who trusts them, and what credentials they accept.
Trust flows through relationships: If you trust Organization A, and Organization A vouches for Organization B, you can evaluate that path. Trust is transitive, auditable, and explicit.
Interoperable with C2PA: DTO doesn’t replace C2PA signatures — it augments them. A C2PA manifest can reference a DID. A verifier can check both the cryptographic signature and the trust graph.

What This Means in Practice

For a small studio:

Without DTO: You need an X.509 certificate from a CA on the C2PA Trust List. Cost: $500-5,000/year. Timeline: days to weeks for validation.

With DTO: You create a DID, publish your trust.json, and establish relationships with organizations in your network — your clients, your vendors, your industry associations. When someone verifies your work, they can trace trust through relationships they already recognize.

For a freelance creator:

Without DTO: You’re largely locked out of the C2PA trust ecosystem unless you pay for a certificate or use a platform that signs on your behalf (giving up control).

With DTO: You can prove your identity through your domain, your social presence, and your relationships with organizations that vouch for you. No certificate required.

For an enterprise client:

Without DTO: You trust work signed by CAs on the C2PA list. Full stop.

With DTO: You can define your own trust policy. Maybe you trust the C2PA Trust List plus any studio that’s a member of an industry association. Maybe you trust any creator vouched for by a publication you respect. Your policy, your rules.

Works With CAs, Doesn’t Require Them

This isn’t anti-CA. Certificate Authorities serve a real purpose — they perform validation, they maintain revocation infrastructure, they have legal accountability.

DTO is additive:

If you have a CA-issued certificate, great. It’s one more trust signal.
If you don’t, you can still participate in the trust ecosystem through relationships.
Verifiers can require both, accept either, or define custom policies.

The point is choice. Trust shouldn’t be gated by who can afford a certificate. It should be gated by who has demonstrated trustworthiness through their relationships and track record.

The Ecosystem Opportunity

C2PA has built something genuinely good. The manifest format is sound. The cryptography is solid. The adoption is real.

But trust infrastructure should reflect how trust actually works in the real world. Organizations don’t trust each other because a third party issued a certificate. They trust each other because of relationships, reputation, and shared context.

DTO brings that model to content authenticity:

Decentralized: No single list controls who’s trusted
Transparent: Trust relationships are public and auditable
Composable: Build trust ecosystems for your community
Accessible: No certificate paywall for participation

Join the Conversation

We’re building this in the open. The trust.json spec is published. The Decentralized Trust Overlay architecture is documented. We’re running pilots with publishers, newsrooms, and studios.

If you’re thinking about content authenticity and running into the CA wall, let’s talk. Not about buying something — about whether this model solves real problems you’re facing.

c2pa@noosphere.tech

Spec: github.com/noosphere-technologies/trust-json-spec

Reference implementation: noosphere.tech/.well-known/trust.json