Proof‑Backed Auctions: Using ads.cert 2.0 to Rebuild Trust in a Post‑Identifier Bidstream

The supply side of ad tech is in a new trust cycle. Third‑party cookies are constrained, mobile IDs are limited by platform policies, and CTV rarely exposes device IDs at all. Buyers still want scale and outcomes, but they are increasingly asking a different question: if you cannot hand me a deterministic user identifier, can you prove the transaction itself is authentic and untampered? That question points to a durable answer: cryptographic proof. ads.cert 2.0 is the IAB Tech Lab protocol suite that lets sellers sign and verify the critical hops in the supply chain so auctions become proof‑backed rather than trust‑based. Done right, this helps SSPs, publishers, and SSAI partners defend value, curb spoofing, and command premium demand without leaning on the bidstream identifiers that are fading. This article lays out why proof‑backed auctions matter now, what ads.cert 2.0 includes, how sellers can implement it across web, app, and CTV, and where this fits with existing transparency standards like ads.txt, app‑ads.txt, sellers.json, buyers.json, SupplyChain Object, and OpenRTB evolution. We will keep this practical and seller‑oriented, with concrete examples and implementation notes, while grounding key points in current standards and industry context.

The Case for Proof‑Backed Auctions

Programmatic’s original trust model depended heavily on user‑level identifiers. As those signals recede, two realities collide:

• Fraud follows the money, and CTV has a lot of it. SSAI spoofing and app misrepresentation remain lucrative without stronger origin authentication.
• Buyers are rebalancing risk. They will pay for quality, but they want reliable ways to tell legitimate from questionable supply when identity‑based signals are limited. Proof‑backed auctions rebase trust on cryptographic assurances tied to the supply path, not the user. That change benefits sellers too:
  • Revenue defense: Authentication makes it materially harder to spoof your apps, channels, or SSAI endpoints, which helps protect CPMs.
  • Premium access: More buyers will transact with explicit requirements for authenticated connections in CTV and for tamper‑evident delivery as it matures.
  • Operational clarity: Authenticating key hops reduces noisy IVT flags and makes discrepancies easier to triage because you know who actually invoked what, and when.

  ads.cert 2.0 in Plain English

  ads.cert 2.0 is not a single spec. It is a suite designed by the IAB Tech Lab’s Security Foundations Working Group to secure programmatic ad delivery with cryptography, with particular emphasis on CTV where SSAI is common. Four core components matter to sellers:

  • Call Signs: Publish your public keys and metadata in DNS so counterparties can discover and verify you.
  • Authenticated Connections: Sign server‑to‑server requests with an HTTP header so recipients can cryptographically verify the sender and detect tampering.
  • Authenticated Delivery: Bind critical bid parameters to a signature so downstream tampering in multi‑hop supply becomes evident to buyers.
  • Authenticated Devices: Let devices attest legitimacy with OEM support to reduce bot and device farm IVT in CTV and beyond.

  The Call Signs and Authenticated Connections pieces are available today with open‑source reference code. Authenticated Delivery and Authenticated Devices are moving through industry testing and maturation. The direction is clear: standardize signatures across the supply chain and make it practical for all sides to verify. Sources: IAB Tech Lab public release and documentation, plus independent trade coverage that tracks the protocol evolution [1][2][3].

  Why The “Post‑Identifier Bidstream” Amplifies ads.cert’s Value

  Identifier deprecation is not a one‑day event, and it is uneven across platforms. Still, the direction is consistent:

• Browsers are limiting cross‑site tracking, driving adoption of contextual, cohorts, and on‑device APIs.
• App platforms have tightened access to device identifiers, particularly on iOS.
• CTV rarely transmits device IDs, and SSAI obscures device‑level identity anyway. Across these environments, the bidstream’s identifying power is weaker. That puts a premium on supply‑path authenticity. Even when you cannot pass a person‑level identifier, you can pass verifiable proof of origin and integrity for the transaction. That shift is strategically good for quality sellers. It channels buyer scrutiny toward things you can control: your systems, your partners, your keys, and your signatures.

  How ads.cert 2.0 Works for Sellers

  Let us zoom into the components that matter for sellers and how to implement them in real systems.

  1) Call Signs: Publish Your Identity

  Call Signs tells the world where to find your public key and how to authenticate you. It uses DNS TXT records, which makes discovery straightforward and low overhead. Example DNS TXT record format for an ads.cert delivery key:

  _delivery._adscert.example-ssp.com. 3600 IN TXT "v=adcrtd k=x25519 h=sha256 p=BASE64URL_PUBLIC_KEY"

  Fields:

  • v: Version token for the record type, typically “adcrtd”.
  • k: Key algorithm identifier, currently “x25519”.
  • h: Hash algorithm identifier, currently “sha256”.
  • p: URL‑safe base64 of the 32‑byte public key.

  The IAB Tech Lab’s open‑source repo includes test domains and example DNS records that demonstrate discovery and verification mechanics [3]. Practical tips:

  • Separate keys by functional role: Use distinct keys for SSAI endpoints, ad server callbacks, and billing beacons to simplify blast radius if you need to rotate.
  • Automate rotation: Treat keys like any other secret. Put rotation on a scheduled runbook tied to deployment windows.
  • Document ownership: Ensure SRE and security teams know who owns the records and the validation SLAs.

  2) Authenticated Connections: Sign Your Server‑to‑Server Calls

  Authenticated Connections binds request elements to a signature in a standardized HTTP header so the receiver can verify the sender identity and detect tampering of content, URL, or destination. Header example (from the IAB Tech Lab open‑source implementation):

  X-Ads-Cert-Auth: from=adscerttestsigner.dev&from_key=LxqTmA&invoking=adscerttestverifier.dev&nonce=6Rpf4qD2LP_9&status=1&timestamp=220912T200513&to=adscerttestverifier.dev&to_key=uNzTFA; sigb=OcQzM62rkJk0&sigu=_44H63NN69Nb

  Semantics:

  • from: Domain of the sender.
  • from_key: Short form of sender’s public key.
  • invoking: Hostname being invoked.
  • to: Domain of the intended receiver.
  • to_key: Short form of receiver’s public key.
  • timestamp: UTC time of signature creation.
  • nonce: Random value to mitigate replay attacks.
  • sigb/sigu: Signatures binding the message and optionally the URL to detect tampering.

  Why this matters in CTV and SSAI: SSAI often proxies the user device, which makes it easy for an impersonator to fake impression pings or app context. If the SSAI and SSP mutually authenticate and sign, illegitimate servers cannot produce valid signatures. Invalid or missing signatures become reliable signals for filtering. Industry guidance explicitly flags Authenticated Connections as a priority for SSAI hardening [1][2]. A minimal cURL example of sending a signed GET to your verifier endpoint:

  curl -H 'X-Ads-Cert-Auth: from=ssai.example.com&from_key=AbCdEf&invoking=ssp.example.com&nonce=9tQeHjK&status=1&timestamp=251022T051000&to=ssp.example.com&to_key=GhIjKl; sigb=Base64SigB&sigu=Base64SigU' \
  'https://ssp.example.com/impression?id=123&slot=preroll'

  Server‑side verification pseudocode in Python‑style pseudocode:

  def verify_adscert_header(request):
  header = request.headers.get("X-Ads-Cert-Auth")
  if not header:
  return VerificationResult(valid=False, reason="missing_header")
  fields, sigs = parse_header(header)  # split message params from sigb/sigu
  # 1) Look up public keys via DNS for fields["from"] and fields["to"]
  sender_pub = dns_lookup_adscert_key(fields["from"])
  receiver_pub = dns_lookup_adscert_key(fields["to"])
  if not sender_pub or not receiver_pub:
  return VerificationResult(valid=False, reason="key_discovery_failed")
  # 2) Reconstruct message canonical form
  body_hash = sha256(request.body or b"")
  canonical = canonicalize(fields, body_hash, request.url)
  # 3) Verify signatures
  valid_sigb = verify_signature(sender_pub, canonical.for_body, sigs["sigb"])
  valid_sigu = verify_signature(sender_pub, canonical.for_url, sigs["sigu"])
  # 4) Check nonce freshness and timestamp skew
  if is_replay(fields["nonce"]) or is_skewed(fields["timestamp"]):
  return VerificationResult(valid=False, reason="replay_or_clock_skew")
  if valid_sigb and valid_sigu:
  return VerificationResult(valid=True)
  return VerificationResult(valid=False, reason="signature_mismatch")

  Production implementations should use the IAB Tech Lab’s reference code or compatible libraries for canonicalization, key exchange, and signature formats [3]. Remember to log invalid signature reasons with structured dimensions so you can operationalize remediation with partners.

  3) Authenticated Delivery: Make Tampering Evident to Buyers

  As supply paths lengthen, data can change downstream. Authenticated Delivery commits key bid fields to a signature at the source, and the buyer verifies that no intermediary modified price floors, app bundle, geo, or other sensitive parameters. While this is still maturing, sellers should design now for an eventual world where your ad server or upstream SSP produces a signed envelope, and each hop preserves that envelope. If a parameter changes, the signature no longer matches. That is the essence of proof‑backed delivery [1][2]. Implementation‑ready recommendations:

  • Schema planning: Agree with partners on which fields will be covered and how you will pass the envelope without breaking existing OpenRTB routing.
  • Logging: Store the signed field set at impression time alongside your final auction logs so you can reconcile buyer complaints with cryptographic truth.
  • UI readiness: Plan to expose a “proof trail” to buyers in deal troubleshooting flows.

  4) Authenticated Devices: Reduce Sophisticated IVT in CTV

  Authenticated Devices will rely on OEM‑level attestations to prove that a device is legitimate and in good standing. For sellers, this is powerful in CTV to filter device farms and headless environments that are otherwise hard to detect with basic heuristics. Keep an eye on OEM and OS partner roadmaps, and ensure your SSAI and verification stack can ingest, store, and act on device attestations when they become available at scale [1].

  How ads.cert Fits with Existing Transparency Standards

  Sellers already rely on ads.txt/app‑ads.txt, sellers.json, buyers.json, and the SupplyChain Object to describe who is allowed to sell what and how buyers can validate paths. ads.cert complements, rather than replaces, those tools:

  • ads.txt and app‑ads.txt: Authorize selling partners. Necessary for allow‑listing but does not authenticate runtime requests.
  • sellers.json: Publicly lists seller accounts and relationships so buyers can map seller IDs to legal entities [4]. Helps reduce opaque arbitrage.
  • buyers.json: Buy‑side mirror that lets publishers and SSPs understand the buyer and its intermediaries [5].
  • SupplyChain Object (schain): Encodes the chain of custody in the bid request. Useful for metadata audit but not tamper‑proof on its own.
  • OpenRTB 3.0 direction: Introduced stronger separation of transport and semantics and laid groundwork for signed bid requests tied to ads.cert [6][7].

  Put simply: the JSON‑based transparency standards tell you who should be involved. ads.cert tells you whether the specific transaction you received actually came from them and whether key fields stayed intact in flight. Sources: IAB Tech Lab specs and primers that describe these relationships and the original vision for signed requests [4][5][6][7].

  CTV First, But Not CTV Only

  CTV is the ripest ground for ads.cert adoption because SSAI is a prime target for spoofing and because the absence of user identifiers is the norm. The IAB Tech Lab and multiple sell‑side and measurement leaders have explicitly positioned ads.cert 2.0 as a CTV fraud reduction mechanism [1][2]. However, the same mechanics apply to:

  • Web header bidding: Signing server‑side requests between Prebid Server and SSPs reduces impersonation and clarifies which endpoint actually invoked the call.
  • Mobile app SDK callbacks: Signing postbacks to verification and measurement endpoints helps ensure the calls originate from authorized SDK components or servers.
  • Billing and discrepancy resolution: Signing reconciliation pings ties financial events to an authenticated chain, which reduces the surface area for disputes.

  A Seller‑Side Implementation Blueprint

  Here is a pragmatic rollout plan for SSPs, publisher ad ops, SSAI vendors, and intermediaries that want to get started. Start small, prove value, and scale.

  • Phase 1 — Call Signs and Discovery: Publish DNS keys for your core domains. Stand up a simple internal tool to check discovery across your inventory and partner matrix. Report coverage weekly to leadership.
  • Phase 2 — Authenticated Connections for SSAI: Instrument signatures on impression beacons and ad decisioning calls between your SSAI and SSP. Validate with a friendly buyer or measurement partner. Track invalid signature rates, top failure causes, and remediation steps.
  • Phase 3 — Expand to Ad Server and Billing: Sign ad server callbacks, creative fetches, and billing notifications. Correlate signature validity with IVT flags and discrepancy deltas to quantify business impact.
  • Phase 4 — Prepare for Authenticated Delivery: Align on the field list to be bound. Prototype the signed envelope with one SSP path. Design schemas and storage to support downstream proof retrieval.
  • Phase 5 — Operationalize Proof: Expose a “Proof Coverage” insight in sales collateral and UI. Offer deal terms that require authenticated connections in CTV. Set internal SLAs for key rotation, invalid rate thresholds, and remediation timelines.

  Management checklist:

  • KPIs: Signature coverage%, invalid signature rate, share of authenticated spend, IVT reduction rate on authenticated paths, time‑to‑resolution for signature errors.
  • Security hygiene: Key rotation policy, audit trails for DNS changes, alerting for anomalous invalid spikes.
  • Partner compliance: Contractual language requiring authenticated connections for SSAI, with clear exceptions handling.

  Real‑World Integration Notes

  A few common pitfalls and how to avoid them:

  • Clock skew: Timestamp verification is part of replay protection. Make NTP a hard requirement and set acceptable skew windows conservatively.
  • DNS caching: Public key discovery happens through DNS. Respect TTLs but add proactive refresh on failures to reduce flakiness during rotations.
  • Key rotation: Coordinate rotations with partners where possible. Support multiple active keys during a grace window to avoid downtime.
  • Proxy confusion: SSAI often sits behind load balancers or CDNs. Ensure the domain in the signature reflects the entity that controls the key and that the receiver checks the “invoking” host correctly.
  • Error taxonomies: “Invalid signature” is not useful without a reason code. Classify by missing header, bad key, timestamp skew, canonicalization mismatch, or body hash mismatch to drive faster fixes.

  Example: Signing an SSAI Impression Ping

  Below is a conceptual example tying it together. The SSAI emits an impression ping to the SSP. Both sides have published keys via Call Signs. The SSAI signs the request. DNS records:

  _delivery._adscert.ssai.videoedge.io. 3600 IN TXT "v=adcrtd k=x25519 h=sha256 p=KZ3vG1Y0wK9n0I89IS3TgU8pUj3hZ0b1kS4gTQd3p_Y"
  _delivery._adscert.ssp.exchange.net.   3600 IN TXT "v=adcrtd k=x25519 h=sha256 p=2l7wZVqgP3xfqvRtlbJH1Opwq0mAnmW3m8aCk5yFKgw"

  HTTP request from SSAI to SSP:

  GET /impression?req_id=abc123&pod=2&pos=1 HTTP/1.1
  Host: ssp.exchange.net
  X-Ads-Cert-Auth: from=ssai.videoedge.io&from_key=KZ3vG1&invoking=ssp.exchange.net&nonce=ZfWq9UCkV&status=1&timestamp=251022T050747&to=ssp.exchange.net&to_key=2l7wZV; sigb=csZ...&sigu=Q1x...
  User-Agent: VideoEdgeSSAI/1.2

  SSP verification flow:

  • Resolve sender and receiver DNS keys, cache them, and compute shared secret.
  • Canonicalize the request URL and body hash.
  • Verify sigb and sigu against the expected values.
  • If valid, mark the log line as authenticated and pass the request to the ad server or measurement pipeline.
  • If invalid, reject or quarantine depending on policy, and include reason in logs.

  Aligning Buyer Expectations and Seller Promises

  To turn proof into revenue, codify expectations with buyers:

  • “Authenticated CTV” packaging: Offer CTV deals that require Authenticated Connections. Publish coverage percentages and target 95%+ within priority channels.
  • Proof dashboards: Share reports with buyers showing signature coverage, invalid rates, and remediation steps by app, channel, and SSAI partner.
  • Contract language: Align IO terms with authenticated supply path requirements and define fallback rules for non‑compliant inventory.

  As Authenticated Delivery matures, expect RFP language to include tamper‑evidence checks on bid parameters. Prepare your product and ops teams for a world where cryptographic receipts are table stakes.

  Where Red Volcano Fits

  Red Volcano’s mission is to arm the supply side with intelligence. Proof‑backed auctions create a new signal layer that our customers can act on. Here is how a publisher discovery and analysis platform can help:

  • ads.cert readiness map: For web, app, and CTV publishers, surface whether Call Signs are present, which domains publish keys, and whether known SSAI endpoints are authenticated.
  • SSP and SDK tech tracking: Map which monetization partners and SDKs support Authenticated Connections and plan to support Authenticated Delivery.
  • ads.txt/app‑ads.txt/sellers.json health: Correlate transparency file coverage with ads.cert adoption to prioritize outreach.
  • Proof coverage benchmarks: Provide market baselines by category and region so sales teams can position proof as a competitive strength.
  • Alerts: Notify when a partner’s DNS key disappears, when invalid signature rates spike, or when a reseller path is missing proofs.

  For SSPs, these signals feed acquisition and QA workflows. For intermediaries, they help rationalize reseller paths and reduce the risk of carrying tainted supply.

  The Business Case: ROI and Time‑to‑Value

  You do not need the entire suite to realize benefits.

• Authenticated Connections between SSAI and SSP yields immediate fraud reduction and more buyer confidence in CTV.
• Call Signs is a fast lift that unlocks subsequent steps and signals seriousness to partners.
• Early design for Authenticated Delivery accelerates your ability to meet buyer requirements as they roll out. Time‑to‑value:
  • 0‑30 days: Publish keys, validate discovery, and pilot Authenticated Connections with one SSAI and one measurement partner.
  • 30‑60 days: Expand to top CTV apps and channels. Instrument logs and dashboards. Add deal packaging for authenticated CTV.
  • 60‑120 days: Extend signatures to ad server callbacks and billing, and complete a prototype for Authenticated Delivery envelopes with one SSP path.

  ROI model inputs:

  • IVT reduction: Improvement in chargeable impressions when illegitimate SSAI traffic is filtered.
  • CPM uplift: Premium buyers or PMPs conditioned on proof coverage.
  • Ops savings: Fewer discrepancy hours and faster triage due to clear invalid reasons.

  Frequently Asked Design Questions

  • Does this require OpenRTB 3.0? No for Authenticated Connections. It uses HTTP headers and works with today’s server‑to‑server flows. Authenticated Delivery and signed bid envelopes align with the vision from OpenRTB’s evolution, so readiness helps [6][7].
  • Is ads.cert only for CTV? No. It is relevant wherever server‑to‑server calls carry important events: web header bidding, SDK callbacks, billing, and verification.
  • Will this replace ads.txt and sellers.json? No. Those remain the source of truth for authorization and identity mapping. ads.cert adds runtime authenticity and tamper evidence.
  • What about privacy? ads.cert signs transport and parameters, not people. It enables trust without increasing exposure of personal data, which is aligned with privacy‑by‑design.

  Implementation Artifacts You Can Reuse

  Code generation and verification are best done with a battle‑tested library. The IAB Tech Lab provides an open‑source proof‑of‑concept in Go with a gRPC interface for signing and verifying headers [3]. You can deploy it as a sidecar:

• Signatory service runs alongside your SSAI or ad server.
• Your application asks the signatory to sign outgoing requests.
• Your receiver calls the signatory to verify incoming signatures. gRPC method interface from the open‑source repo:

  rpc SignAuthenticatedConnection(AuthenticatedConnectionSignatureRequest)
  returns (AuthenticatedConnectionSignatureResponse) {}
  rpc VerifyAuthenticatedConnection(AuthenticatedConnectionVerificationRequest)
  returns (AuthenticatedConnectionVerificationResponse) {}

  This architecture lets you treat signature logic as a service, decoupled from business code, and rotate keys centrally.

  What Good Looks Like in 2025

  By the end of the year, a high‑performing seller stack should hit these marks:

  • 95%+ signature coverage on SSAI‑originated CTV impression and event traffic across top channels.
  • < 0.5% invalid rate attributable to controllable causes, with the remainder triaged and documented with partners.
  • Signed ad server callbacks for major events and signed billing beacons for reconciliation.
  • Buyer‑facing proof dashboards integrated into deal reporting.
  • Authenticated Delivery prototype in active testing with at least one major SSP path.

  Publishers with this posture will be positioned to weather further identifier changes, monetize curated and private marketplaces more efficiently, and differentiate in crowded CTV categories where app spoofing has historically muddied the waters.

  Conclusion: Proof Over Promises

  The post‑identifier bidstream does not have to be a lesser version of programmatic. It can be a more resilient one if we shift the trust anchor from people identifiers to cryptographic proof of the transaction itself. ads.cert 2.0 gives the supply side a practical toolkit to do that today. Start with Call Signs and Authenticated Connections to harden SSAI and core server‑to‑server flows. Prepare now for Authenticated Delivery, so when buyers ask for tamper‑evident bid parameters you are already there. Pair these with the transparency standards you already run and turn proof into a go‑to‑market asset that earns premium demand. Sellers who move first will not simply reduce fraud. They will change the conversation with buyers from what you claim to what you can prove.

  References

  1) IAB Tech Lab — Public Release of Ads.cert: Securing the CTV Supply Chain — https://iabtechlab.com/public-release-ads-cert-securing-the-ctv-supply-chain/ — Accessed Oct 22, 2025 2) The Drum — IAB Tech Lab escalates attack on CTV ad fraud with ads.cert 2.0 — https://www.thedrum.com/news/2021/09/30/iab-tech-lab-escalates-attack-ctv-ad-fraud-with-adscert-20 — Accessed Oct 22, 2025 3) IAB Tech Lab GitHub — ads.cert open source (Authenticated Connections) — https://github.com/IABTechLab/adscert — Accessed Oct 22, 2025 4) IAB Tech Lab — Sellers.json (specification PDF) — https://iabtechlab.com/wp-content/uploads/2019/07/Sellers.json_Final.pdf — Accessed Oct 22, 2025 5) buyers.json working site — https://www.buyersdotjson.org/ — Accessed Oct 22, 2025 6) eMarketer — What Marketers Need To Know About Ads.cert — https://www.emarketer.com/content/what-marketers-need-to-know-about-ads-cert — Accessed Oct 22, 2025 7) IAB Tech Lab — Innovation Day materials referencing signed bid requests and OpenRTB direction — https://iabtechlab.com/wp-content/uploads/2019/05/FINAL_Tech_Lab_Innovation_Day_Supply_Chain.pdf — Accessed Oct 22, 2025 8) Google Authorized Buyers — OpenRTB integration guide (context on OpenRTB transport and adoption) — https://developers.google.com/authorized-buyers/rtb/openrtb-guide — Accessed Oct 22, 2025 9) Industry overview: progress on SSAI vulnerabilities and the role of Authenticated Connections — https://videoweek.com/2021/10/18/are-we-making-progress-on-ssais-fraud-vulnerabilities/ — Accessed Oct 22, 2025 Notes:

• The examples and code are illustrative and draw on the IAB Tech Lab open‑source documentation and public articles for accuracy.
• The adoption status of Authenticated Delivery and Authenticated Devices varies by partner and market; design for forward compatibility now to reduce future rework.