Understanding the IAB Framework in 15 Minutes (or less!)

Let’s take a deeper look into the IAB Transparency and Consent Framework (TCF). In 2018, this framework was introduced by the international advertising business organization called the Interactive Advertising Bureau (IAB), to help the digital advertising ecosystem comply with obligations under the GDPR and ePrivacy Directive.

But before we begin, it must be noted that this Framework can be quite overwhelming due to its complexity of combining two factors:

1. A consent interface for end users, publishers, advertisers and
2. GDPR compliance.

Thankfully, this difficulty is handled by Consent Management Platforms (short CMPs) which will make it a lot easier for you, as a user to understand and to use IAB’s Transparency & Consent Framework.

In the next 15 minutes, you will not only be able to:

• describe what the TCF is
• understand which problem the TCF tries to solve

But also…

• learn how the framework works and why a CMP is necessary for it

The IAB Transparency & Consent Framework (TCF) was set up to standardize and simplify the communication of handling consent between a publisher and advertisers. Therefore providing an answer to the question of how to deal with advertiser chains.

According to the TCF, the publisher has to be able to find out if the user agrees to certain technologies processing data. More precisely, “purposes on how personal data may be processed by which company” e.g. tracking tools, end-user identifying cookies.

Remember: ever since the GDPR came into effect, it is insufficient to simply inform the user about what will happen to his or her data. Key is that there must also be a possibility present where the user can allow or reject the processing of his or her personal data. And in case you are wondering what “personal data” consists of, personal data is just about every bit of data out there seeing as every ID (including the IP-Address) is understood as personal data.

So what does this mean? This legally states that all technologies which are used on any given website can only use the website users’ data if there was in fact, consent given. But how will the technology itself, advertiser or any other member of the third-party chain receive this information and know that they are legally allowed to use data?

The key is, as always, communication!

And that’s exactly what the IAB TCF does; it helps to communicate and share consent information between third-party vendors, your website and the end user so that every stakeholder on the technology chain understands that consent either has or has not been given. No, if’s and or maybe’s to be seen in sight!

The short answer is that many stakeholders are involved. On the one side, all third-party technologies and publishers need to know if they are allowed to use the user data they received. While on the other side, the user needs to know what is going to happen with his or her data. This is why the IAB has defined a set of standard purposes (e.g. “Information storage and access” or “personalization”) and holds a list of registered third-party vendors. The registration as a Vendor is done via an application process. Vendors must specify the purposes of processing data and included features. They also have to indicate the link to their privacy policy which needs to be GDPR-compliant. The IAB is in charge of managing and governing the TCF and vets if the application adheres to the framework policy. CMPs like Usercentrics provide an efficient and simple solution as they present the user with the registered vendors and the purposes that the publisher has selected.

Are you wondering how it is even possible to successfully communicate with several technologies and websites at the same time? The answer is easy: by using the same language. IAB offers a unified method to create, encode and decode the information in the form of a single character string, appropriately called “consent string”. As an example, it could look like this:

“BObFBzjObFBzjAFABBDECD-AAAAjyABAGqA”

This short character string contains a lot of information like purposes or vendors that the user has given consent for. It also contains additional information, e.g. the string version or when it was last updated. Even though this may look very complicated and incomprehensible, no need to worry, you as a publisher will not be required to read the character string. The character string will be created by a CMP, a legal requirement, seeing as only IAB verified CMPs can create valid consent strings.

If questions such as “what if the publisher creates a consent string by itself?”, “How will a vendor know that this string was not created by a registered CMP?” pop up in your head, just know that you are not alone. The answer is: by using cookies. Each registered CMP receives their own subdomain at mgr.consensu.org e.g. usercentrics.mgr.consensu.org. The CMP will then set a cookie on this domain once they have created a consent string. Other websites cannot set cookies for those specific subdomains. So the Vendor can check at anytime if the consent string can be found in a cookie on the CMP subdomain. If it cannot be found, the consent string is considered as invalid.

The wave is moving fast. An updated version of the IAB Transparency and Consent Framework (TCF 2.0) is currently in the making. Over the past 12 months, stakeholder feedback from the publisher community has been sought. Moreover, there was a public comment period which ended on the 25th May 2019. Once the technical specifications and policies have been finalised, detailed implementation manuals will be issued for all concerned parties (vendors, publishers and CMPs). So far, no release date has been confirmed.

The most significant, planned changes in TCF 2.0:

• Increased focus on legitimate Interest:For certain purposes (“Purposes”), vendors can by default rely on “legitimate Interest”. The user can object to this.
• Purposes:The number of purposes has increased significantly (from 5 to 10). In addition, there are two so-called Special Purposes, which cannot be objected to as a user (e.g. from security and/or Fraud Detection reasons)
• Special Features: These features require their own opt-in, e.g. the use of geolocation data.
• Technical descriptions in the mobile surroundings (For example: How are consents stored in Apps, in a standardised manner?)