Privacy Architecture

How TMP separates user identity from page context, what each party can and cannot learn, and how TEE attestation upgrades the guarantee.

Privacy Architecture

TMP’s privacy model is structural, not policy-based. The protocol separates user identity from page context so that buyers never receive both together. Without TEE, this separation is enforced by code: the context code path never accesses identity data and vice versa. The code is open-source and auditable. With TEE, attestation proves the expected code is running unmodified, upgrading the guarantee from “auditable” to “independently verifiable.”

This page explains what the separation is, what it prevents, and where the guarantees come from. TMP is the only AdCP domain that enforces privacy structurally — see Privacy posture across domains and the cross-protocol Privacy Considerations page for how this compares to other domains.

The Separation Principle

The TMP Router is a single binary with two structurally separate code paths: one for context, one for identity.

	Context Path	Identity Path
Inputs	Page URL, content signals, topic IDs	Opaque user token, package IDs
Never receives	Any user identity	Any page context
Returns	Activated packages, enrichment signals	Eligible package IDs + TTL (seconds)

The context code path has no access to identity data. The identity code path has no access to context data. The two paths share no state: no shared memory, no shared database, no communication channel, no shared logs or telemetry.

Without TEE

Separation is enforced by the code itself. The context path cannot read identity data because it is not passed to it, not stored in any location the context path can reach, and not referenced in any data structure the context path processes. The same applies in reverse for the identity path.

This is verifiable by reading the source code. The router is open-source. Anyone can audit it to confirm that the two code paths are isolated. But this is a trust-and-audit model: you are trusting that the deployed binary matches the published source, and that no modification has been introduced at runtime.

With TEE

TEE (Trusted Execution Environment) attestation removes the need to trust the operator. An attestation document is a cryptographically signed statement of exactly what code is running inside the enclave. A publisher or auditor can:

1. Obtain the attestation document from the router.
2. Verify the signature against the TEE vendor’s root certificate authority.
3. Confirm that the running code matches the published, audited source.

This makes the separation independently verifiable. No one needs to trust the router operator’s claim that they deployed the right binary; the hardware proves it.

TEE is an upgrade path, not a prerequisite. The protocol works without it. Publishers who need independent verification can require TEE-attested routers; those who are comfortable with code audit and operational trust do not need to.

What Each Party Learns

What the buyer agent learns

From Context Match requests, a buyer agent learns:

• Which publisher placements and content artifacts exist
• Content signals via context_signals (topics, sentiment, keywords, language, brand safety tier, summary, embedding) — pre-computed by the publisher
• Geographic context (country, region, metro) — publisher-controlled granularity

From Identity Match requests, a buyer agent learns:

• Which user tokens exist (opaque, publisher-scoped)
• Whether each user is eligible for each of the buyer’s active packages
• Cross-identity equivalence within the publisher’s view: when an IMR carries multiple identities entries, the buyer learns that those tokens resolve to the same user from this publisher’s perspective. This is an intentional match-rate optimization, but it is also identity-graph enrichment the buyer did not previously have. Publishers who want to avoid disclosing cross-graph joins can send a single (user_token, uid_type) per IMR at the cost of match rate.
• Sensitive token exposure: hashed_email and similar strongly-reidentifying tokens carry higher re-identification risk than opaque provider IDs. Publishers SHOULD treat inclusion as a deployment decision, not a default. When the buyer agent runs in a TEE-attested deployment, the risk surface shrinks to what the buyer’s model can infer from the match outcome rather than what a logged payload can reveal post-hoc — TEE does not eliminate the disclosure but it closes the offline-retention vector. Non-TEE deployments should weigh hashed_email inclusion against legal/consent posture.

The buyer computes eligibility internally from frequency caps, audience membership, purchase history, or whatever signals they have. They return a list of eligible package IDs and a TTL. The publisher does not learn why a user is or is not eligible.

What the buyer cannot do:

• Associate a user token with a page URL or content signal
• Determine that a specific user visited a specific page
• Build a cross-page browsing profile for any user

These limitations hold because the buyer never receives identity and context in the same request, and the decorrelation mechanisms described below prevent joining them after the fact.

What the router operator learns

The context code path sees content signals and package lists. It fans these out to buyer agents and merges responses. It never processes user tokens.

The identity code path sees user tokens and package IDs. It fans these out to buyer agents and merges responses. It never processes content signals.

Without TEE, the operator could theoretically modify the binary to bridge the two paths. The code is open-source and auditable, but you are trusting the operator to run it unmodified. With TEE, attestation proves the binary matches the published source, removing that trust requirement.

Router trust boundary for identity filtering

The router is in the trusted boundary for Identity Match forwarding. When the router filters the identities array per provider (sending only tokens the provider’s declared uid_types include), providers cannot independently verify what the publisher originally sent — they see only the filtered subset signed by the router. This is a deliberate trust placement: the router already performs structural separation of the two code paths, and filtering identity tokens is a simpler guarantee than separating code paths.

The router MUST NOT add, substitute, or transform identity tokens. The forwarded identities MUST be a subset of the publisher-origin array. This invariant is provable from code audit (without TEE) and cryptographically verifiable from attestation measurements (with TEE). Operators running non-TEE deployments accept code-audit as the basis for this invariant; operators running TEE-attested deployments get independent verification.

Buyers close a residual risk at the protocol layer: when multiple identity types are present, buyers SHOULD prefer opaque provider IDs over hashed_email and other strongly re-identifying tokens, so that even a router that strips everything except hashed_email does not gain leverage (see Responding to Identity Match).

What the publisher retains

The publisher has both context and identity. They are the first party: the user is on their page, using their app, in their conversation. TMP does not change the publisher’s data posture. It prevents buyers and intermediaries from obtaining the same combined view.

The publisher performs the join locally after both responses arrive. They can apply consent logic, frequency management, and relevance ranking on their own infrastructure.

TMPX exposure tokens and structural separation

The Identity Match response can include a tmpx field carrying a TMPX token — an HPKE-encrypted blob containing the user’s resolved identity tokens. This token flows through creative tracking URLs to the buyer’s impression pixel for per-user exposure tracking.

This data flow bridges the identity and context paths: the TMPX token is produced by Identity Match and consumed via creative tracking URLs that originate from Context Match offers. However, the bridge happens publisher-side — the publisher joins the two responses locally and substitutes the TMPX value into tracking URLs during ad serving. The buyer’s read replica produces the encrypted token. The buyer’s impression pixel receives it. The publisher sees only an opaque blob and MUST NOT parse, log, or make decisions based on its value.

The TMPX token does not violate structural separation because:

• The router never sees the decrypted contents — it passes the opaque tmpx field through.
• The publisher substitutes the value into tracking URLs without interpreting it.
• Only the buyer’s cluster master can decrypt the token (HPKE mode_base — encrypted with the master’s public key, only the master’s private key can decrypt).
• The country routing directive on the Identity Match request is stripped by the router before forwarding — the buyer agent never sees which country the user is in.

Package Set Decorrelation

If the context path sent only the packages relevant to this page, and the identity path sent only those same packages, a buyer could compare the two sets and infer which page the identity request came from. TMP prevents this by requiring structurally different sets:

• Context Match sends no package list. The provider evaluates its synced package set for the placement — stable per placement, the same for every user. Because no packages are sent per request, the publisher cannot accidentally leak identity through package filtering.
• Identity Match sends package_ids (or omits it entirely, in which case the buyer evaluates against its full registered active set for seller_agent_url). When sent, composition MUST be statistically independent of the current placement — either all-active (every active package for this buyer at this publisher) or fuzzed (a random sample optionally padded with synthetic non-existent IDs that the buyer silently drops). The buyer evaluates the user against this set, not against just the page-specific subset.

The context set is scoped to one placement. The identity set is scoped to one buyer’s entire active inventory. The two sets are structurally different, and neither reveals information about the other.

The publisher performs the intersection locally: which packages were both activated by context match and eligible by identity match.

Temporal Decorrelation

Even with separate code paths and different package sets, if Context Match and Identity Match requests arrive at a buyer at the same instant — or always in the same order — from the same publisher, timing or ordering correlation is possible. TMP addresses both:

• Publishers SHOULD introduce a random delay between context and identity requests. The recommended range is 100-2000ms, uniformly distributed.
• Publishers SHOULD also randomize the order: each opportunity SHOULD have a roughly equal probability of context match going first or identity match going first. A fixed order leaks the pairing through ordering even when the delay is randomized.
• Publishers MAY batch Identity Match requests across multiple page views, further obscuring which context request each identity request corresponds to.
• Publishers MAY route context and identity requests through different network paths.

Temporal decorrelation is defense in depth. It is not the primary separation mechanism; structural separation and package set decorrelation are. But it closes the timing side channel.

TEE Attestation Details

TMP’s reference architecture targets AWS Nitro Enclaves, though the protocol is TEE-agnostic. Any TEE that produces verifiable attestation documents is compatible.

What attestation proves

• The router binary running inside the enclave matches the published, audited source code.
• The code paths for context and identity are structurally separate, with no shared state.
• The binary has not been modified by the operator, the hosting provider, or any runtime process.

What attestation does not prove

• That buyer agents handle the data they receive responsibly. TMP limits what buyers receive; it does not control what they do with it.
• That the publisher’s join logic is correct. The publisher is the first party and is not constrained by TMP’s separation model.
• That the code is free of bugs. Attestation proves the code matches the published source. Whether that source is correct is a separate question, addressed by open-source audit.

Attestation measurements

Each attestation document includes cryptographic hashes of the running environment:

Measurement	What it covers
Image hash	Hash of the enclave image. Confirms the binary matches the expected build.
Kernel hash	Hash of the operating environment.
Application hash	Hash of the application-level code.
Role hash	Confirms the enclave’s permissions match expectations (e.g., no access to external databases).

A publisher or auditor can verify these measurements against the published build artifacts. This verification can be automated and performed continuously.

Comparison to OpenRTB

Signal	OpenRTB	TMP
User ID + page URL	Same bid request	Separate code paths, never combined
Device fingerprint	Included in bid request	Never sent
IP address	Included in bid request	Never sent
Raw cookies	Included in bid request	Never sent
GPS coordinates	Included in bid request	Never sent
Browsing history	Constructible via cookie sync	Not constructible: buyer never sees identity + context together
Separation verification	Trust the exchange	Code audit (without TEE) or TEE attestation (with TEE)

In OpenRTB, the bid request is a bundle of everything: user identity, device signals, page context, behavioral data. Every participant in the auction receives the full bundle. Privacy depends on contractual promises not to misuse the data.

TMP splits the bundle at the protocol level. Buyers receive context or identity, never both. The separation is structural, not contractual.

Regulatory Posture

TMP’s structural separation aligns with the data minimization principle required by GDPR, CCPA, ePrivacy, and similar regulations:

• Buyer agents never receive user identity paired with content context. Minimization is enforced by the protocol, not by policy.
• The publisher, as the first party with a direct user relationship, controls the join. They can apply consent logic before combining the datasets.
• With TEE attestation, the separation is independently verifiable, providing auditable evidence for regulators.

This is an architectural observation, not legal advice. Publishers and buyer agents should consult their own legal counsel regarding regulatory compliance.

For a detailed analysis of how TMP’s architecture maps to GDPR controller and processor roles, see Data Protection Roles. For cross-protocol privacy guidance, see Privacy Considerations.