The Transparency and Consent Framework (TCF) is an effort to manage user consents, and have all parties understand the users consent information from regulations like GDPR.

Consent Management Platforms (CMP) helps sites to collect and manage user consent information in the TC data format. Today AMP allows a CMP to integrate with some limitations.
The <amp-consent> CMP integration was designed to work with any framework that is based on a consent string format.

CMP scripts are executed in an CORS iframe that’s controlled by AMP instead of included as first party script. Because AMP handles the lifecycle of the iframe, CMPs don’t have flexibility on when to show its UI, or has the ability to provide mandatory APIs for vendors to get their TC data.

What has Changed

In the past year, the IAB TCF v2.0 has been widely adopted by most vendors. Unlike a year ago when we first designed the feature, now we don’t see the necessity to support other TC framework. This allows AMP to work together with CMPs to understand the TC data and TCF v2 APIs.

With more regulations like GDPR, we are seeing the increasing complexity for site owners to manage user consents. Thus we are seeing the trend to have more CMPs come into the area. That brings a lot more feature requests and many ask for feature parity between AMP and their non-AMP integrations.

Goal

The goal of the design revise is to come up with a solution so that

1. Vendors don’t find integrating with AMP challenging due to user consent handling.
2. CMPs and publishers get flexibility to manage consent prompt without hurting general user experience.
3. AMP pages are still performant.
4. AMP doesn’t take the liability in managing user consent data.
5. Engineering effort is manageable.

Proposed solutions

Option 1

Allow CMP script to run in the background, it will still run in a CORS iframe, but it will be initiated at pageload time and always run in the background.
This is very similar to the CMP, non-AMP pages integration as much as possible.

Details

• Different ad vendors will have different ways to call the TCF standard APIs
  • Fast Fetch: AMP can proxy the __tcfapi() method and send postMessage to CMP iframe
  • In iframe: Same with non AMP, Let vendor communicate with CMP iframe __tcfapiLocator directly using postMessages.
  • Analytics vendors can’t use the TCF standard APIs. AMP can provide macros for them to get vendor specific data from the TCData object. But we will start with the entire consent string.

Pros:

• Vendors can follow the same implementations, as the same set of APIs will still be supported by CMPs.
• Because the CMP iframe runs in the background. It has the flexibility to request to display the UI.
• Easy implementation from the AMP side. As CMPs have all APIs provided, AMP simply passes messages between different parties.
• This may also enable publishers to work together with CMP to manage vendors that’s not only the GVL list, as long as the two parties reach some agreement on format. (Need declarative inline config added)

Cons

• Having CORS iframe running in the background can lead to performance and security concerns.

Option 2

This is the current approach. Pass the entire TC data consent string using AMP provided APIs

Design Details

• AMP will provide APIs for vendors to get the complete TC data in the consent string format.
  • 3P Ad vendors can use the context.initialConsentValue
  • Fast fetch vendors can use the getConsentPolicyInfo() method
  • Analytics vendor and RTC request can use the CONSENT_STRING macro

Pros

• No extra work on the AMP size. Support future version of the framework by default.
• Passing TC data and handling them on the server end is the best for performance.

Cons

• CMPs don’t get flexibility on the consent UI.
• Difficulties for vendors to interpret TC data on the client side.
• Ads vendors need to import libraries to do so. This can be a blocker for future vendors to integrate.

To decide if we need to change the design, we'd like to get feedback from CMPs, Ad vendors, Analytics vendors and Publishers.
We are leaning towards Option 2 (The existing option) for performance reason. If so

1. How difficult it is for ad vendors to interpret consent string without the TCF APIs
2. Are analytics vendors OK with handling the consent string on server side?
3. What's the limitation to CMPs having AMP runs their code in CORs iframe, and controls the lifecycle of the iframe?

cc @ampproject/wg-analytics @ampproject/wg-ads