# For newsrooms, AI platforms & camera makers — Content Credentials people can actually verify > content.whisper.online · for newsrooms, AI platforms & camera makers ## 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. **We close both.** Anchor your C2PA / CAWG signer in your **own DNSSEC/DANE zone** — the address **is** the signer — so anyone verifies it with `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. **Prove your content →** https://console.whisper.security/sign-up ### The proof strip - **$12.3B → $40B** — GenAI/deepfake fraud 2023 → 2027 (~32% CAGR, Deloitte). - **0.1%** — of people correctly told a real from a deepfake (n=2,000, iProov). - **2 Aug 2026** — EU AI Act Article 50: machine-readable marking of AI output goes live. - **~$289/yr** — per signer cert, and an off-list creator shows "unknown source." - **write-only** — C2PA gives a signer zero view of who verified their content. - **2025** — a camera vendor had to revoke its *entire* C2PA device-cert set after one vuln. --- ## The manifest is solved. The trust around it isn't. 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. - **STRIP — 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. - **UNKNOWN SIGNER — 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*. - **WRITE-ONLY — 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. --- ## Two gaps. Every provenance program has both. 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. ### Gap 1 · you can't prove the signer without joining someone's list 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. **Diagram — signer serial/key → verifiable, revocable name.** A C2PA claim-signer's public key, named by its X.509 certificate serial carried in the `COSE_Sign1` `x5chain` (EKU `c2pa-kp-claimSigning`), derives a routable `/128` (`2a04:2a01:c0f::515`); DNSSEC and a DANE-EE `3 1 1` TLSA record in the signer's own zone anchor it into a name anyone can verify (`whisper verify --trustless`) with no C2PA Trust-List slot; `op:revoke` tears a compromised signer down worldwide at DNS-TTL — the revocation C2PA leaves optional and slow. > **"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." ### Gap 2 · after you publish, you're blind — and impersonable 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 — billions of nodes and 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. **Diagram — close the write-only loop.** A signed asset with its Content Credential is distributed across platforms. Standard offline C2PA validation makes no network call — but each verifier that *opts into* the DANE trust source resolves the signer's anchor, generating DNS, TLSA and RDAP lookups against Whisper's authoritative servers; `op:lookups` feeds those resolutions back to the signer as who-verified analytics and an impersonation tripwire, while the attribution graph fingerprints a host reusing the identity assertion. Provenance becomes a two-way channel. > **"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. --- ## Who this is for — four seats, one primitive 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. --- ## Where we fit — stated plainly 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. Plus 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. ### Positioning table | 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. --- ## Three planes on one primitive 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. **Diagram — three planes into your stack.** Three planes — signer identity (`signer /128 · DNSSEC · DANE-EE · bound to the C2PA cert serial`), verification analytics (`op:lookups — who verified your content`), and egress governance (`per-signer /128 · policy · firewall · budget · revoke`) — rest on one primitive (the address is the signer, `AS219419 · 2a04:2a01::/32`) and exit into the content stack you already run: your C2PA/CAWG manifest, the verifier tools (contentcredentials.org · Chrome · Search), and the tamper-evident Bitcoin-anchored transparency log. Whisper never creates the manifest or embeds a watermark; it anchors the signer they reference and adds the analytics and revocation they lack. - **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. --- ## Prove it in 60 seconds — no account 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. ### Verify a signer — keyless · attribute an impostor — graph API ```bash # 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: · seen across AWS / GCP / a residential swarm evidence chain: signed · replayable — hand it to a takedown desk unchanged ``` ### Anchor, watch & revoke your signer — with your key ```bash # 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:'', 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 roadmap ``` --- ## Where Whisper fits The 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 →](/compare) --- ## 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. **Prove your content →** https://console.whisper.security/sign-up Or run `whisper verify --trustless` right now. --- *Identity on the wire for content provenance. AS219419 · 2a04:2a01::/32. © 2026 viaGraph B.V. (dba Whisper Security).*