C2PA proves the pixels weren't changed. It can't tell your reader whether to trust the signer.
Content Credentials are the right idea, done well — a tamper-evident manifest of who, when, and what edits. But two holes stay open: an off-list signer displays "unknown source" unless it buys onto a coalition-curated Trust List (~$289/yr, no ACME, no Let's Encrypt for provenance), and once your content is out you are write-only — zero visibility into who verified it or who's impersonating your byline. Neither hole is a manifest problem. Both are an identity problem.
dig, no Trust-List slot and no CA fee, revocable worldwide at DNS-TTL; and op:lookups finally shows you who checked. Content Credentials people can actually verify.
whisper verify --trustless — anchored at the IANA DNS root. Our own API is not in the trust path.
A signed manifest tells you what happened to the bits. It doesn't tell you who to trust — or whether anyone believed you.
The C2PA spec is explicit that its trust rests on "an identity ecosystem substantiating the signing key belongs to the Signer" — and equally explicit that it provides the signature format and a curated CA list, not that public identity ecosystem. Here is exactly where that leaves you.
The credential is easily separated
The manifest lives in embedded JUMBF metadata; any non-C2PA-aware resave — including a screenshot — deletes it. The spec concedes it: "a screenshot eliminates any trace of provenance." A durable watermark helps recovery; a signature alone does not.
Off-list looks identical to malicious
The spec permits self-signed and off-list certs, so an independent's manifest is technically indistinguishable from an impostor's — both render "unknown source." There is no free, ACME-style path to become a recognized signer, and revocation checking is optional.
You never see who checked
C2PA verification needs no network call — the cert chain travels in-band per RFC 9360 — so a signer has zero visibility into who verified their content, where, or how often. No early warning that your byline is being reused or your credential stripped.
Strip down the whole problem and it isn't a hundred bugs in the format — the format is good. It's two structural gaps in the trust layer around the format, and every provenance program shares both. Close them and Content Credentials become something a reader — or a regulator — can actually act on.
One is a signer you can't verify without a gatekeeper. The other is silence after you publish.
Both are the kind a skeptic names on sight — not a compliance checkbox. Here they are, and here's exactly how each closes without forking C2PA.
A conformant validator trusts a signer only if its cert is on an explicit allow-list or chains to a root on a trust-anchors list — a list a small coalition curates and a CA charges to enter. An off-list newsroom, stringer, or agent signs perfectly valid content that still reads "unknown source." The burden shifts to every verifier to somehow resolve who this signer really is.
The answer — a signer anchored in your own DNS. C2PA trust lists and anchors are pluggable config inputs to the validator — so a DNSSEC/DANE anchor is a legitimate alternative trust source, not a fork. Derive your C2PA claim-signer's routable /128 from the signer key it already holds, publish a TLSA (DANE-EE 3 1 1) that pins the end-entity cert in your own DNSSEC-signed zone, and any verifier that consults DANE trusts it with no central list, no gatekeeper, and no annual CA fee. This is the mechanism C2PA's own experimental "Web Domain Trust Anchor" reached for — done with DNSSEC instead of an HTTPS /.well-known/c2pa.json that fails on domain takeover.
"Isn't a DANE-anchored signer just you deciding you're trusted? How is that not a fork of C2PA?"
It isn't a fork — it's a config input C2PA already supports. Trust lists and trust anchors are pluggable inputs to a conformant validator; a DNSSEC/DANE anchor is a legitimate alternative source, surfaced through a CAWG identity assertion and consumable exactly like any other. The reader's trust roots in the IANA DNS root, not in us. Honest limit: DANE is not yet a formally recognized C2PA conformance anchor — we position it as a complementary identity ecosystem, never as "C2PA-approved."
Once content leaves you, provenance is write-only. You cannot see who verified it, where it travelled, or where the credential got stripped — and an attacker can lift your valid identity assertion onto a new asset to falsely wear your brand. C2PA's own security model names this brand-impersonation risk; nothing in the format gives you a feedback loop.
The answer — reverse observability + the graph. Because your signer's name resolves through Whisper's own authoritative DNS and RDAP, op:lookups returns who resolved or validated your signer — the TLSA/AAAA/RDAP checks a verifier makes — turning provenance into a two-way channel: a verification-analytics stream and an early warning that someone is enumerating or impersonating your byline. And when a suspicious host is reusing your identity assertion, the attribution graph — 7.44B nodes, 39.3B relationships of fused BGP, DNS, WHOIS, TLS and hosting — fingerprints the operator across rotating clouds and residential proxies and hands you a reproducible evidence chain for a takedown.
op:lookups turns that resolution into a signal you can read: who checked it, and who's wearing your byline without permission."C2PA verification is offline by design — the certs travel in the manifest. So how could you possibly know who verified my content?"
Because your signer's identity is online even though the manifest is offline. The manifest still verifies with no network call — that's unchanged. But when a validator checks your DANE-anchored signer, it resolves DNS/TLSA/RDAP records that live on our authoritative servers, and op:lookups reports exactly those. It's a capability C2PA structurally can't offer — and the honest early-warning you've never had.
Gap 1 makes your signer trustable off any list. Gap 2 makes it observable. Both ride your existing Content Credentials untouched — now here's who tends to move first, and exactly where we do and don't fit.
Four people carry this problem — and each one buys the same primitive for a different reason.
Different triggers, different vocabulary, one mechanism underneath: the address is the signer. Find your seat.
A · Newsroom · publisher · press-freedom org
Trigger: the AI-image flood and the liar's dividend; major wire services and publishers are already adopting Content Credentials through the CAI and Project Origin; you want Content Credentials that verify without a coalition gatekeeper or a ~$289/yr per-cert tax on your stringers.
Lead: a verifiable, revocable byline/org signer anchored on your own domain — readers verify "signed by signer.newsroom.example" straight from DNS, no Trust-List slot, no annual CA fee, and verification analytics show where your content travelled and where credentials were stripped.
You say: provenance · chain of custody · Content Credentials · first-mile capture · "how we verified this" · source protection · Project Origin.
B · AI platform · agent maker
Trigger: EU AI Act Art.50(2) obliges you to mark generative output machine-readable and detectable-as-AI by 2 Aug 2026, with the digitalSourceType = trainedAlgorithmicMedia assertion — and Recital 133 names "cryptographic methods for proving provenance" as an accepted technique.
Lead: sign your outputs' C2PA claim (plus a CAWG identity assertion) with a DANE-anchored identity derived from the agent's existing key — trusted-signer status without a Trust-List slot or CA fee. Honest split: the DANE-anchored signer identity + DNS-TTL revocation is shipped & live today; a first-class sign-outputs tool that emits the C2PA/CAWG claim for you is on the roadmap.
You say: synthetic-content marking · detectable-as-AI · durable vs soft binding · provenance signal · output attribution · IPTC digitalSourceType.
C · Camera · device maker
Trigger: in-camera Content Credentials are now table-stakes (Leica/Sony/Nikon/Canon, first native smartphone) and newsroom procurement requires them — but the 2025 mass-revocation incident, where a vendor had to pull its entire device-cert set after one vuln, exposed how brittle a per-model root is.
Lead: per-unit revocable device signer identities derived from each device's hardware key — so a single compromised unit is one DNS op:revoke, not a fleet-wide suspension. Per-unit trust, one identity plane across the fleet, interoperable by construction (open DNS/DANE, not a proprietary silo).
You say: point-of-capture · hard binding · secure element · certificate lifecycle · firmware attestation · per-unit vs per-model.
D · Stock library · marketplace · platform
Trigger: Art.50 deployer duties, label/remove statutes, and Google bringing C2PA verify into Search and Chrome push verification to your ingest — while the trust-list equity gap makes you penalize legitimate small and independent signers you'd rather recognize.
Lead: verify signer identity at ingest — publicly, at scale, with a DNS-resolvable anchor and no private allow-list — and get the who-verified analytics C2PA can't provide. Extend the trust list past the whitelist and detect the strip.
You say: trust & safety · at-scale verification · soft/hard bindings · manifest validation · trust list · false-positive rate.
A fifth seat too: the fact-checker or evidentiary desk that needs to resolve a claimed signer in public DNS in seconds — not just read a manifest — and catch the impostor cert. Everyone verifies keyless; only the signer needs a key.
The strongest thing we can say is also the most honest one: we fill C2PA's own stated dependency, and nothing more.
Over-claiming here is the credibility trap, so we draw the line for you before a red-teamer does. Three tiers: what we do today, what we complement, and what we will not claim.
● Direct — additive, today
An additive, pluggable C2PA trust anchor: your signer's EE cert pinned via DANE in your own DNSSEC zone, consumable as a validator config input. And a CAWG path — run your own did:web ICA issuer and DANE-bind cawg.web_site + the cawg.x509.cose org cert to your domain. We anchor the signer your manifest already references.
◐ Complementary — evidence, not a route
EU AI Act Art.50 support: a public cryptographic provenance anchor is a named technique (Recital 133) and advances the interoperable/robust/public bar — as a feature and evidence, never a conformity route. ISO 22144 procurement: an accessible public signer identity helps you meet the language — not a certification.
✕ We do not claim
Not official C2PA Trust-List membership. Not a C2PA-conformance or EU-AI-Act-conformity route. Provenance ≠ truth, and we are not a deepfake detector. We do not survive a manifest-stripping re-encode. Each one, spelled out below.
| Claim | Status | What it means — and its limit |
|---|---|---|
| Additive, pluggable C2PA trust anchor (DANE-EE) | ● DIRECT | C2PA trust anchors are pluggable validator inputs; a DNSSEC/DANE anchor is a legitimate alternative source, not a fork. Shipped & live. |
CAWG did:web issuer + cawg.web_site DANE-bind | ● DIRECT | Run your own ICA issuer and bind the domain identity CAWG already carries. The primitive is live; a turnkey issuer tool is on the roadmap. |
| EU AI Act Art.50 marking support | ◐ COMPLEMENTARY | A named technique (Recital 133) and public-verifiability evidence — advances the bar. Not a conformity route; the AI-generated assertion lives in the manifest, we anchor the signer. |
| ISO 22144 procurement fit | ◐ COMPLEMENTARY | Accessible public signer identity helps satisfy procurement language as Content Credentials enter it. Not a certification. |
| Official C2PA Trust-List membership | ✕ NOT CLAIMED | We are not on the coalition-curated Trust List; we are a complementary, domain-owner-controlled trust source you choose to consult. |
| A C2PA-conformance / EU-AI-Act-conformity guarantee | ✕ NOT CLAIMED | Technology-neutral. We evidence and strengthen; no product "makes you compliant." |
| Provenance = truth · a deepfake detector | ✕ NOT CLAIMED | A signature proves who + integrity, not veracity and not "this is AI." Absence of a credential ≠ fakery — pair with watermarking/detection. |
| Survives a screenshot / manifest-stripping re-encode | ✕ NOT CLAIMED | A re-encode separates the credential. We improve recovery odds and detect the strip via analytics, but can't prevent it — that's a durable watermark's job. |
The one-sentence version: C2PA proves a manifest was signed; we make the signer publicly, independently verifiable in DNS — the identity layer C2PA depends on but doesn't provide — so your Art.50(2) machine-readable mark is anchored to a real, resolvable identity, no curated allow-list required. See the full comparison →
Three planes on one primitive — and all three exit into the Content Credentials pipeline you already run.
The primitive is one line: the address is the signer — a routable IPv6 /128 out of 2a04:2a01::/32 (announced by AS219419), DNSSEC-anchored, DANE-EE pinned, verifiable by anyone with dig. Point it at your signer and you get identity, analytics, and governance — no new silo, and the manifest stays yours.
Nothing issued in the dark
Every signer identity minted and every revocation lands in a public, append-only RFC 6962 Merkle transparency log, Ed25519-signed and anchored to Bitcoin via OpenTimestamps — an auditable issuance and revocation trail a regulator or a court can replay. Honest status: tamper-evident and Bitcoin-anchored today; independent external witnessing is the next step, and we already speak the C2SP witness protocol so any third party can co-sign.
Govern what a signer may reach
A per-signer /128 with a graph-first resolver and source-bound egress enforces default-deny — allow the timestamp authority and your ledger endpoint, block the rest — with op:firewall, op:budget caps, and op:revoke to cut a compromised signing service off worldwide in one call.
Sign-outputs, honestly staged
Today: derive a DANE-anchored signer /128 from your generator's or agent's own key and pin it — a trusted-signer identity with no Trust-List slot. On the roadmap: a first-class sign-outputs tool that emits the C2PA claim with digitalSourceType = trainedAlgorithmicMedia plus a CAWG identity assertion, so Art.50(2) marking rides your Whisper identity end to end.
Additive & availability-safe
It rides existing DNS/IPv6 and adds no chokepoint in your signing path. If a verifier authorizes against the DANE/verify path, that plane is built to fail open — a Whisper outage degrades to the anchors you already ship, never a false "invalid." Anycast on AS219419, no single node in the path.
Don't take our word for it — our API isn't in the trust path.
Two tiers, by design. No key: anyone resolves a signer's identity and back-traces an impostor — trustless, anchored at the IANA root. Your key: anchor your signer on your own domain, see who verified it, and revoke a compromised one worldwide.
# keyless — resolve and verify a newsroom's C2PA signer identity, trustless
$ whisper verify --trustless signer.newsroom.example
✓ DNSSEC chain valid to the IANA root
✓ DANE-EE (TLSA 3 1 1) pins the C2PA claim-signer EE cert
✓ RDAP: registered under AS219419 · 2a04:2a01::/32
signer: VERIFIED — no C2PA Trust-List slot, no CA phone-home
# the serial your manifest carries → its DANE-anchored pin, in the signer's OWN zone
$ dig +short TLSA _443._tcp.signer.newsroom.example
3 1 1 5f2b9c…e41 ; the claim-signer EE cert, DNSSEC-signed by the newsroom
# who really operates a host reusing your identity assertion — the public graph API
$ curl -s https://graph.whisper.security/api/query -H "X-API-Key: whisper_live_xxx" \
-H 'content-type: application/json' -d '{"query":"CALL whisper.identify(\"203.0.113.9\")"}'
operator: <fingerprinted> · seen across AWS / GCP / a residential swarm
evidence chain: signed · replayable — hand it to a takedown desk unchanged# anchor your C2PA signer identity on your OWN domain, from the key it already holds
$ export WHISPER_API_KEY=whisper_live_xxx
$ curl -s https://graph.whisper.security/api/query -H "X-API-Key: $WHISPER_API_KEY" --data-urlencode "q=CALL whisper.agents({op:'connect', args:{tier:'wireguard',
identity_public_key:'<base64 SPKI of your C2PA signer key>',
device_id:'5F2B9C0A4E11D7…'}})" # device_id = the signer cert serial
→ identity 2a04:2a01:c0f::515 DNSSEC + DANE-EE (TLSA 3 1 1) live
# publish the TLSA pin + point cawg.web_site at this name — off-list signer, now publicly verifiable
$ whisper logs 2a04:2a01:c0f::515 --lookups # op:lookups — WHO verified your content
1,284 validations · 37 countries · 2 checks from a host not on your allow-list ⚠
$ whisper policy set --default deny --allow tsa.example,ledger
$ whisper revoke 2a04:2a01:c0f::515 # a compromised signer, gone worldwide at DNS-TTL
# a first-class `whisper sign-outputs --c2pa` (emits the claim + CAWG assertion) — on the roadmapThe manifest, the edit history, the watermark, the in-camera capture — all done well. We anchor the one thing they leave open.
C2PA/CAI build a tamper-evident manifest; watermarking (SynthID, Meta Seal) adds an AI-origin signal that survives a screenshot. Both are necessary and neither is what we do — Whisper does not create the manifest or embed the watermark. We anchor the signer those manifests already reference, publicly and off any list, and we close the two quadrants nobody else occupies: signer trust the domain owner controls, and the feedback loop that shows who verified your content.
| C2PA / CAI provenance | Watermarking (SynthID / Seal) | Whisper | |
|---|---|---|---|
| Tamper-evident manifest (who · edits · tools) | ✓ | — | additive |
| Invisible signal surviving a screenshot / re-encode | — | ✓ | — |
| Publicly verifiable signer — no central Trust List | — | — | ✓ |
| Cross-org signer trust without joining a list | — | — | ✓ |
| Signer revocation at DNS-TTL, one call | — | — | ✓ |
| Who verified your content (analytics) | write-only | write-only | ✓ |
Depth on top of the Content Credentials you already emit — it makes an off-list signer publicly verifiable, gives it an off-switch, and turns verification into a signal you can read. It doesn't replace C2PA, and it doesn't add a console your team babysits. See the full comparison →
Content Credentials people can actually verify.
Anchor your C2PA / CAWG signer in your own DNSSEC/DANE zone — publicly verifiable, revocable at DNS-TTL, with the who-verified loop C2PA never closed. Additive to your manifest, never a replacement. Keyless to try, one call to anchor, one more to revoke.
Or run whisper verify --trustless right now.