You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Investigate and document mechanism to pass user consent to downstream partners #156
@jevansnyc@aram356 Here are a few details on how Trusted Server should handle user consent and pass it to downstream partners.
This is a fundamental architectural decision that impacts implementation complexity, publisher control, and compliance monitoring.
Context
In client-side implementations, the CMP collects consent and makes it available via the euconsent-v2 cookie (TC String for GDPR) and the TCF API. Third-party scripts consume the TCF API directly to check what they can do with user data and whether they can serve personalized ads. Each vendor is responsible for reading and interpreting the consent string properly.
In server-side implementations with Trusted Server, the CMP still collects consent and stores it in cookies, but now Trusted Server sits between the website and downstream partners. TS receives the consent information via cookies (when the cookie domain matches the TS domain) and needs to pass this consent to downstream partners who perform programmatic advertising.
The question is: how should TS pass this consent?
How it works today in OpenRTB and Prebid Server
Currently, OpenRTB and Prebid Server pass raw consent strings and let downstream partners handle the decoding:
Different downstream partners use different schemas. OpenRTB and Prebid Server have different structures. Each vendor is responsible for decoding the TC String or GPP String and extracting the purposes, vendors, special features, and publisher restrictions they need.
The core question: Proxy or Interpreter?
Should Trusted Server act as a consent proxy (passing raw strings like OpenRTB does) or as a consent interpreter (decoding strings and passing structured data)?
Option 1: Consent Proxy (pass raw strings)
TS receives the TC String or GPP String from cookies and passes them unchanged to downstream partners. TS adds minimal metadata like gdpr=1 and geolocation signals. Each downstream partner decodes the string in their Trusted Server module.
Pros:
Simpler TS implementation
Follows existing OpenRTB pattern
Each partner applies their own compliance logic
No risk of TS misinterpreting consent
Clear responsibility boundaries
Cons:
Every downstream partner must implement TC String / GPP decoding in their TS module
TS has no visibility into what consent was actually given
Can't monitor which vendors receive what consent
Can't log consent usage patterns
Can't audit compliance
Publishers have no observability into consent usage in server-side flows
Black box for monitoring and debugging
Option 2: Consent Interpreter (decode and pass structured data)
TS receives the TC String or GPP String, decodes them using iabtcf/core and gpp/core, and passes structured decoded data to downstream partners. This could be purposes, vendors, special features, publisher restrictions in a normalized format.
Pros:
Centralized decoding (one implementation instead of N partners)
TS can monitor and log consent usage
Publishers get visibility: "Vendor X received consent for purposes 1,2,3"
Can audit compliance in real-time
Easier for smaller downstream partners
TS can apply publisher-level business rules
Observability and control
Cons:
More complex TS implementation
TS must maintain iabtcf/core and gpp/core libraries
Breaking change from OpenRTB pattern
TS must update when specs change (TCF 2.2 → 2.3, new GPP sections)
Needs to define a new normalized schema
Legal responsibility for correct interpretation
Scenarios where this matters
Scenario A: No cookie in Europe (GDPR)
Under TCF specs, you cannot create a TC String until the user has been shown the notice. So if there's no cookie, this is a signal that no consent has been collected yet.
With the proxy approach, TS passes:
The absence of the consent string IS the signal. Downstream partners understand: no consent collected, serve non-personalized ads only.
With the interpreter approach, TS would need to generate some structure representing "no consent", but this feels like creating synthetic consent data.
Scenario B: No cookie in US states (GPP)
In some US states, users can be opted in by default, so websites can process user data and display targeted ads before the user interacts with any notice. But the GPP string might not be created yet if the CMP hasn't loaded, creating a race condition.
With the proxy approach, TS needs publisher-configured defaults per geolocation. If no GPP string is present but the user is in California, TS could pass a default string like "1YYN" (opted out by default per CPRA) based on publisher configuration.
With the interpreter approach, TS would decode this default and pass structured data.
If consent has expired (based on the LastUpdated timestamp in the TC String and publisher-defined validity period like 13 months), the old cookie is still present but shouldn't be used.
Both approaches need to handle this, but the question is: should TS check expiration and validity, or should downstream partners do this?
Why this matters for server-side implementations
The big difference from client-side is observability and control. In client-side, publishers have limited visibility into what third parties do with consent. In server-side, Trusted Server is the orchestration layer. If TS just passes raw strings without decoding them, publishers lose the opportunity to monitor and audit consent usage.
This is particularly important for:
Debugging consent issues
Compliance auditing
Publisher dashboards showing consent metrics
Detecting vendors that ignore consent signals
Real-time monitoring of consent violations
My recommendation
I think we should start with the interpreter approach (Option 2) because the observability and control it provides is fundamental to the value proposition of server-side consent management. Yes, it's more complex, but the ability to monitor consent usage in real-time is critical for publishers moving to server-side implementations.
However, I want to hear from the community on this. Are there concerns I'm missing? Is the proxy approach sufficient and we're overengineering? Should TS provide both modes?
Open questions
If we go with the interpreter approach, what schema should TS use to pass decoded consent data to downstream partners?
Should TS enforce consent expiration checks or leave that to downstream partners?
How do we handle the case where both TC String (GDPR) and GPP String (US) are present (user traveled from EU to US)?
Should TS provide configuration for publisher-specific defaults per geolocation?
What's the liability model if TS misinterprets consent data?
I agree with your recommendation of option 2 to utilize the TS benefits. Open Questions comments:
I think we can consult IAB TL folks on this one for json schema
I think it should, yes, but can be turned off. Keep in mind TS is not an "entity" so if it is enforcing the ownership and responsibility would still fall to the pub
Activity
[-]Investigate and document[/-][+]Investigate and document mechanism to pass user consent to downstream partners[/+]jevansnyc commentedon Feb 9, 2026
Jason discussing with Valentin
cmdvuy commentedon Feb 11, 2026
@jevansnyc @aram356 Here are a few details on how Trusted Server should handle user consent and pass it to downstream partners.
This is a fundamental architectural decision that impacts implementation complexity, publisher control, and compliance monitoring.
Context
In client-side implementations, the CMP collects consent and makes it available via the euconsent-v2 cookie (TC String for GDPR) and the TCF API. Third-party scripts consume the TCF API directly to check what they can do with user data and whether they can serve personalized ads. Each vendor is responsible for reading and interpreting the consent string properly.
In server-side implementations with Trusted Server, the CMP still collects consent and stores it in cookies, but now Trusted Server sits between the website and downstream partners. TS receives the consent information via cookies (when the cookie domain matches the TS domain) and needs to pass this consent to downstream partners who perform programmatic advertising.
The question is: how should TS pass this consent?
How it works today in OpenRTB and Prebid Server
Currently, OpenRTB and Prebid Server pass raw consent strings and let downstream partners handle the decoding:
OpenRTB format:
Prebid Server format:
Different downstream partners use different schemas. OpenRTB and Prebid Server have different structures. Each vendor is responsible for decoding the TC String or GPP String and extracting the purposes, vendors, special features, and publisher restrictions they need.
The core question: Proxy or Interpreter?
Should Trusted Server act as a consent proxy (passing raw strings like OpenRTB does) or as a consent interpreter (decoding strings and passing structured data)?
Option 1: Consent Proxy (pass raw strings)
TS receives the TC String or GPP String from cookies and passes them unchanged to downstream partners. TS adds minimal metadata like gdpr=1 and geolocation signals. Each downstream partner decodes the string in their Trusted Server module.
Pros:
Cons:
Black box for monitoring and debugging
Option 2: Consent Interpreter (decode and pass structured data)
TS receives the TC String or GPP String, decodes them using iabtcf/core and gpp/core, and passes structured decoded data to downstream partners. This could be purposes, vendors, special features, publisher restrictions in a normalized format.
Pros:
Cons:
Scenarios where this matters
Scenario A: No cookie in Europe (GDPR)
Under TCF specs, you cannot create a TC String until the user has been shown the notice. So if there's no cookie, this is a signal that no consent has been collected yet.
With the proxy approach, TS passes:
The absence of the consent string IS the signal. Downstream partners understand: no consent collected, serve non-personalized ads only.
With the interpreter approach, TS would need to generate some structure representing "no consent", but this feels like creating synthetic consent data.
Scenario B: No cookie in US states (GPP)
In some US states, users can be opted in by default, so websites can process user data and display targeted ads before the user interacts with any notice. But the GPP string might not be created yet if the CMP hasn't loaded, creating a race condition.
With the proxy approach, TS needs publisher-configured defaults per geolocation. If no GPP string is present but the user is in California, TS could pass a default string like "1YYN" (opted out by default per CPRA) based on publisher configuration.
With the interpreter approach, TS would decode this default and pass structured data.
Scenario C: Expired consent requiring recollection
If consent has expired (based on the LastUpdated timestamp in the TC String and publisher-defined validity period like 13 months), the old cookie is still present but shouldn't be used.
Both approaches need to handle this, but the question is: should TS check expiration and validity, or should downstream partners do this?
Why this matters for server-side implementations
The big difference from client-side is observability and control. In client-side, publishers have limited visibility into what third parties do with consent. In server-side, Trusted Server is the orchestration layer. If TS just passes raw strings without decoding them, publishers lose the opportunity to monitor and audit consent usage.
This is particularly important for:
My recommendation
I think we should start with the interpreter approach (Option 2) because the observability and control it provides is fundamental to the value proposition of server-side consent management. Yes, it's more complex, but the ability to monitor consent usage in real-time is critical for publishers moving to server-side implementations.
However, I want to hear from the community on this. Are there concerns I'm missing? Is the proxy approach sufficient and we're overengineering? Should TS provide both modes?
Open questions
Looking forward to the discussion.
jevansnyc commentedon Feb 16, 2026
I agree with your recommendation of option 2 to utilize the TS benefits. Open Questions comments:
I think we can consult IAB TL folks on this one for json schemaAlso, keep in mind TS doesn't strip or manipulate cookies by default, so the base case of today will still be available in corner cases.