Repository navigation
Improving Trusted Server Attestation #1427
Description
User story
Overview
Objective
Increase confidence and “trust” with functionality that ensures a publisher’s Trusted Server instance is running the expected Trusted Server codebase, without silent modifications. This confidence needs to be available at the bid request level.
Problem
Today, Trusted Server offers no reliable mechanism for downstream buyers to verify that a publisher is running a specific, reproducible build of Trusted Server. By design, it isn’t possible to directly observe how inventory is exposed and auctioned within Trusted Server, nor within the supply chain that carries that opportunity down to a buyer.
As a practical example, today a publisher could run a “Trusted Server” solution, and silently inject additional code and functionality that duplicates, id-bridges, manipulates, or misstates the nature of an opportunity – invisibly to the buyer or other participants in the supply chain.
This is arguably worse than the current state – participants will assume the opportunities are safer due to the presence of Trusted Server, and these opportunities become much harder to validate with auction and decisioning logic moving off the client and towards the server.
Without addressing these drawbacks, we risk turning the web from the most transparent channel into a murkier one.
Proposal
Our investment in OpenAds has pointed us to three key attestation ingredients which we firmly believe need to be added to the Trusted Server initiative:
- Establish an independent administrator who is responsible for checking and reporting the integrity of Trusted Server instances against known code.
- Provide cryptographic integrity signatures to downstream ad buying systems on bid requests.
- Provide continuous monitoring and automated, programmatic methods for determining the “trust status” of a given implementation.
This extends Trusted Server in two ways – first by adding an always-on, cryptographically secure method to verify that this environment is actually trustworthy – not just passing self-declared signals.
The second major extension is to append a second, cryptographically-derived signature to individual bid requests. This lets the ecosystem know that the source environment is trustworthy and that the bid request contains the information specified by the publisher – there have not been any silent modifications or overwrites by a third party in the supply chain.
The net result: a trusted and verified server – as well as trusted and verified ad transactions.
Implementation
Roles
Edge Platform
The key technology that enables the Trusted Server -- a CDN that intermediates browser <> server requests and supports compute on the edge. Fastly, Cloudflare and Akamai are some examples. Responsibilities beyond hosting the application include supporting required services like audit logs and service users to enable automated monitoring.
Administrator
The Tech Lab (and other entities) should take on the role of an “Administrator” of the Trusted Server ecosystem, similar to the role that The Trade Desk plays with UID2. In its role as Administrator, the Tech Lab would be responsible for:
- Continuously monitoring enrolled publisher instances– ensuring that the publisher’s Trusted Server instance matches an expected build.
- Reporting status, acting as a root authority.
- Generating publisher public and private key pairs for request signing and validation.
- Stapling publisher requests with signed audit metadata.
Publisher
The actual operator of a Trusted Server instance, the publisher is responsible for:
- Originating bid requests
- Granting edge platform access to the administrator(s) to check and monitor
- Proper configuration and keeping cryptographic data secure
Requirements and Prerequisites
Reproducible Builds
In the Github repository, the Trusted Server project will publish reproducible (wasm) builds. A user must be able to generate a matching build from scratch.
Dedicated Edge Platform Account
A publisher will need to grant access against their edge account to an administrator super user service (ex. an external user service account in Fastly) that is used for monitoring the Trusted Server implementation. This account (or sub-account) should be exclusively dedicated to the Trusted Server and supporting services to avoid actual or apparent key mishandling.
Outermost Layer
The Trusted Server must be deployed in the edge platform as the outermost layer on the domain to guard against bad or unexpected inputs.
Key Functionality
Stapled Audit
The administrator signs an audit with a timestamp, expiry, publisher key thumbprint and instance metadata using its own private key. The instance pulls in the stapled audit from an edge platform config store item and includes it as a component of the bid request's integrity signature (see next item). If a downstream consumer observes that the expiry has passed, the audit is missing or they cannot verify the audit using the administrator's public key, they consider that Trusted Server instance... untrusted.
Integrity Signatures (Signed Requests)
The administrator will upload an Ed25519 private key to the publisher's edge platform account. This private key, available only to known Trusted Server instances, is used to sign request-level payloads that include the stapled audit and core auction data. Downstream platforms can use the administrator-hosted public key against the integrity signature to verify payload integrity from end-to-end.
Note that some configuration fields, such as the type of IP address sharing, may need to move into the integrity signature. We will open an additional issue to fully describe what buyers would like to see here.
Status Endpoint
The administrator exposes the publisher’s status and associated public key on an endpoint intended for downstream consumption, such as:
https://iabtechlab.com/trusted-server/domains/example.com/keys.json
[
{
"version": "hash_of_build",
"jwks": [],
"platform": "fastly",
"status": "valid|inactive|revoked",
"created_at": "datetime",
"checked_at": "datetime",
"inactive_at": "datetime",
"revoked_at": "datetime"
}
]This should replace the publisher-declared JWKS and provides a useful public log of key history to complement the stapled audits in the bidstream.
Initial Registration Flow
- The publisher provides the administrator with the domain(s) that will run a validated Trusted Server instance.
- The administrator provides an identifier to place in e.g. a DNS TXT record to prove domain ownership. For example,
trusted_server_verification=abc123. The administrator validates that the identifier is associated with the domain and that the Trusted Server is the outermost layer on the domain. - The publisher grants the administrator access to its edge platform account.
- The publisher deploys the unchanged, reproducible build of Trusted Server to their edge platform account. The publisher passes their Fastly service id at deploy time (rather than in the package itself) which keeps the hash consistent.
- The administrator verifies that only known builds of Trusted Server are running and it has sufficient access to audit the account. If successful, the administrator will upload a publisher-specific private key back to the publisher’s edge platform account. The administrator will delete its copy of the private key. Finally, the administrator will set its first stapled audit on the platform edge account.
- Signed bid requests may begin to flow.
Ongoing Monitoring
Post-registration, the administrator will continuously monitor the publisher’s edge account. In the ideal case, the administrator will consume a platform-provided audit log from the edge provider, either via event hooks or periodically parsing it. As a fallback, the administrator can poll for changes, but polling introduces greater risk of undetected key exfiltration and misuse.
Downstream platforms – bidders, DSPs, SSPs and others - need to have a clear signal when an integrity signature is no longer valid. The administrator should target checks every few minutes with a maximum expiry on the stapled audit and status page TTL of 15 minutes. On a failed check, the administrator will stop issuing signed audits and mark the publisher's key as revoked. Failing checks (or unavailability) are intended to fail closed.
Future State
If edge platforms begin to support TEEs or more targeted records of service<>binary hash mappings, this proposal can evolve to support stronger hardware-based guarantees with looser monitoring requirements.
Activity
jwrosewell commentedon Oct 22, 2026
Thanks for writing this up Ian. Here's some updates you may not be aware of and then my thoughts on how this should be handled.
Attestation of the Trusted Server operator and the build is running on our version used with techtested.net, a publisher in production. Fetch https://techtested.net/_51d/attestation.json?nonce=anything and the signed evidence comes back with your nonce inside it:
The page at the same path without .json links to the verifier we run. The seven checks a verifier makes are in docs/guide/attestation.md in #1353 (row 12 of our stack of PRs to get everything ready for prime time, design in #1342, closes #161), so anyone holding the operator's public keys can run one.
The build fields have to be self reported because we included some private customizations, which is important for innovation and competition. #1353 explains this. We say which release we deployed. A buyer can verify this.
#1353 follows RFC 9334, which names the Attester, the Verifier and the Relying Party as separate roles, with the Endorser and the Reference Value Provider for whoever produces the thing being attested. Building and signing the release (#1235, #1262) puts Tech Lab in those last two roles. Your proposal adds a "root authority" with a service account on every publisher's edge platform, which generates the publisher's keys, uploads "an Ed25519 private key to the publisher's edge platform account", and signs an audit that goes inside every bid request. Whoever holds that key can sign as the publisher.
You cite The Trade Desk's role in UID2 as the model. The record on that role indicates this leads to centralization and jeopardy.
So the two bodies offered the job, Tech Lab and Prebid.org, both turned it down, and The Trade Desk kept it because it had a commercial reason to. I'm against centralising this in any one body, Tech Lab included. I believe the same logic used to refuse UID2 applies here, there is no point rerunning that, and that the centralization of UID2 is significant problem. The RFC9334 solution puts no limit on the number of verifiers. (Indeed adding RFC9334 verification to other software would be a huge benefit for fraud reduction. Imagine browser client software offering such attestation?!)
@lamrowena, can we get this on the next Task Force agenda? Ian, can you write down what a buyer wants signed per request before then, so the two can be compared at the meeting? @aram356 you're assigned on this issue, so your view on the RFC 9334 split would help.
Footnotes
Anthony Vargas, "A Publisher Didn't Get Its UID2 Setup Right. The Trade Desk Didn't Notice.", AdExchanger, 7 May 2026, https://www.adexchanger.com/identity/a-publisher-didnt-get-its-uid2-setup-right-the-trade-desk-didnt-notice-what-went-wrong/. "When it comes to UID2, the buck stops with The Trade Desk, which serves as the sole administrator for the UID2 protocol." and "The Trade Desk's dual role as a buying platform that makes bidding decisions based on alt IDs and as the only administrator of its own alt ID has been criticized since UID2's initial rollout in 2020." ↩
The Trade Desk, "The Trade Desk Contributes Unified ID 2.0 Source Code to PRAM Technical Working Group via IAB Tech Lab for Open-Source Collaboration", press release, 24 May 2021 (dated from the AdExchanger report of the same day), https://www.thetradedesk.com/press-room/the-trade-desk-contributes-unified-id-2-0-source-code-to-pram-technical-working-group-via-iab-tech-lab-for-open-source-collaboration. "The Trade Desk has contributed the code base of UID 2.0 to IAB Tech Lab, who will make it available under BSD-2 License". Allison Schiff, "The UID 2.0 Code Base Is Officially Open Source", AdExchanger, 24 May 2021, https://www.adexchanger.com/online-advertising/the-uid-2-0-code-base-is-officially-open-source/. "Although it's not official yet, the IAB Tech Lab will most likely serve as the administrator of UID 2.0 with the ability to dole out encryption keys to participants." ↩
Allison Schiff, "Unified ID 2.0 Faces Roadblocks In Europe As A Result Of GDPR", AdExchanger, 15 November 2021, https://www.adexchanger.com/privacy/unified-id-2-0-faces-roadblocks-in-europe-as-a-result-of-gdpr/. "multiple sources tell AdExchanger that The Trade Desk is having trouble lining up an independent administrator to govern and police the use of UID2 in territories where GDPR is the law of the land." and "This administrator would very likely be on the hook for any violations of GDPR, a hefty liability that's scaring off potential administrators." The same article reports Bill Michels of The Trade Desk telling Digiday that "The Trade Desk remains the initiative's sole administrator, although it's looking into other entities that could take on the task." ↩
Allison Schiff, "Why The IAB Tech Lab Still Hasn't Taken On The Administrator Role For Unified ID 2.0", AdExchanger, 16 December 2021, https://www.adexchanger.com/privacy/why-the-iab-tech-lab-still-hasnt-taken-on-the-administrator-role-for-unified-id-2-0/. "During a Tech Lab board meeting last Thursday, a vote on the matter was tabled for further discussion.", "the Tech Lab doesn't feel comfortable taking on the role of admin as currently defined in The Trade Desk's technical specs for Unified ID 2.0", "It's that last bit the IAB Tech Lab board isn't comfortable with, as in pulling the plug if a partner violates UID2's code of conduct." and "The Trade Desk, however, is pushing for an industry entity to take on the responsibility of controlling the kill switch for UID2." ↩
Ronan Shields, "With Prebid at the helm of UID 2.0, indie ad tech marches to a unified beat but not all voices are in harmony", Digiday, 7 January 2022, https://digiday.com/media/with-prebid-at-the-helm-of-uid-2-0-indie-ad-tech-marches-to-a-unified-beat-but-not-all-voices-are-in-harmony/. "Magnite's Garrett McGrath, the interim chairman of Prebid.org, told Digiday the administrator role was offered to both PreBid.org and The IAB Tech Lab, but neither body felt the role of 'ad tech police' within their charter." ↩
Allison Schiff, "The Trade Desk Is Forgoing Public Operators For Unified ID 2.0", AdExchanger, 3 April 2023, https://www.adexchanger.com/privacy/the-trade-desk-is-forgoing-public-operators-for-unified-id-2-0/. "But the hunt for an administrator, which manages access to the UID2 ecosystem, remains ongoing." and "In the meantime, The Trade Desk is fulfilling the admin function, which isn't ideal from an open-source point of view." ↩
Anthony Vargas, AdExchanger, 7 May 2026, as in footnote 1. "The Trade Desk apparently agreed with that assessment at one point, since it tried – in vain – to find a third-party administrator for the UID2 protocol.", "The IAB Tech Lab was once considered for the role of UID2 admin, but declined to take it on." and "Today, the Tech Lab only serves to ensure that the UID2 protocol remains open source, said Shailley Singh, COO and EVP of product at IAB Tech Lab." ↩
jevansnyc commentedon Oct 22, 2026
Thank you for this contribution @decaffeinatedio! We will review and get back with comments asap.
jwrosewell commentedon Oct 28, 2026
Three updates on attestation since the 51Degrees PR review on 23 October.
My comment above pointed to
docs/guide/attestation.mdin #1353 for the checks, and to #1353 for the RFC 9334 roles and why the build fields are the operator's own report. That guide went with attestation. The specification will cover the checks, the roles and the build fields.