A Trusted - and Verified - Server

Objective

Increase confidence and “trust” in Trusted Server with new 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 that at one point in time, the code originated from the Trusted Server initiative.

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.

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 itself include supporting required services like audit logs and service users to enable automated monitoring.

Administrator

The IAB 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 signature.
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 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
Keeping cryptographic data secure

Requirements and prerequisites

Reproducible builds

In the Github repository, the Trusted Server project will begin to publish reproducible (wasm) builds. A user must be able to generate a matching build from scratch. This capability is key to be able to understand expected Trusted Server behaviors.

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 registration and ongoing monitoring of 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 statements

The administrator signs a statement with a timestamp, expiry, publisher key thumbprint and instance metadata using its own private key. The instance pulls in the stapled statement 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 sees that the expiry has passed, the statement is missing, bid request data contradicts the integrity signature, they consider that Trusted Server instance… untrusted.

Integrity signatures (signed requests)

The administrator will upload a Ed25519 private key to the publisher’s edge platform account. This private key, available only to known Trusted Server instances, is used to sign individual outbound requests. Without the signed payload, a company could successfully audit their Trusted Server, modify the code, and rely on an outdated successful audit.

Downstream platforms can use the corresponding, administrator-hosted public key against the integrity signature to verify origin and 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:

iabtechlab.com/trusted-server/domains/example.com/keys.json

keys.jsonJSON

 1[
 2    {
 3        "version": "hash_of_build",
 4        "jwks": [],
 5        "platform": "fastly",
 6        "status": "valid|inactive|revoked",
 7        "created_at": "datetime",
 8        "checked_at": "datetime",
 9        "inactive_at": "datetime",
10        "revoked_at": "datetime"
11    }
12]

This should replace the publisher-declared JWKS and provides a useful public log of key history to complement the stapled statements 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 then validates that the identifier is associated with the domain and that the Trusted Server is the outermost layer on the domain.
The publisher then grants the administrator access to its edge platform account.
The publisher will deploy the reproducible build of Trusted Server unchanged to their edge platform account. When deploying, the publisher passes an e.g. Fastly service id at deploy time which makes the package hash consistent.
The administrator verifies that the only running services are known builds of Trusted Server and it has sufficient access to audit the account. Once verified, the administrator will upload asymmetric key data back to the publisher’s edge platform account. The administrator will delete its copy of the private key after it has been uploaded. Finally, the administrator will upload its first stapled statement to the platform edge account
Signed bid requests 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.

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 statement and status TTL of 15 minutes. On a failed check, the administrator will stop issuing statements and mark the current key as revoked. Failing checks (or unavailability) are intended to fail closed.