On September 25th, we held a 2.5-hour long webinar providing a Complete Overview of the IAB Europe Transparency and Consent Framework. As is usually the case, we had many interested attendees who were keen on learning more. While we usually do our best to make these as interactive as possible, we were simply overwhelmed with questions and had to skip over quite a few to be able to remain on schedule. For this reason, we have decided to answer the questions in a series of blogs. This is the second blog in the series, where we deal with the technical questions about the Framework. Upcoming blogs as part of this Blog Series will cover additional technical questions, as well as policy and legal questions.
What about processing batch file data and not real-time requests? Do you actually need the consent string in the batch data file or can you here rely on a DPA with the data provider?
The Consent String, or daisybit, should be read in each bid request for each unique impression opportunity when passed over real-time bidding (OpenRTB).
Do users of the IAB Europe Transparency and Consent Framework have to provide a specific cookie that they want to investigate for a consent status? Could you clarify how would the investigation work?
The individual will be presented with a user interface (operated by a CMP, displayed on a publisher website page). The individual will then select their consent preferences, and this information then gets stored as a cookie (either as a third-party cookie or site-specific cookie). The user is not expected to investigate the literal cookie itself, but a CMP should offer a way for the user (consumer) to re-select their consent preferences, thereby triggering an update to the cookie that has the consent string record.
Can you define what is covered by ‘open source standard’? Is it a tech standard or does it include language and contractual structure?
The IAB Europe Transparency and Consent Framework has open source technical standards managed by IAB Tech Lab and includes a process of registration (including agreement to terms and conditions), allowing a company to express that they adhere to expected policies.
Well known examples of purely technical ‘open source standards’ include OpenRTB, VAST, or MRAID (each without a “framework” that requires corresponding terms and conditions). These technical standards have a system of community and governance to maintain and upgrade specifications to meet industry needs. Participants contribute to implementation guides, provide use cases, or propose new features. A governing body is able to commit to formal iterations and new versions of the specifications, providing structured pathways to updates.
How does the vendor know that the other vendor to whom it is transmitting the data has received the users consent?
All vendors taking part in the Transparency & Consent Framework are obliged to accept the Terms and Conditions, as well as fully adhere to the policies of the Framework. The first vendor in this scenario has to pass the ‘daisybit’ down the chain upon receiving it themselves, and it is up to the vendor down-stream to appropriately respond to the information therein and pass it further down the chain where applicable.
There is currently no technical signal to indicate that consent has been read or applied, though it is a useful suggestion that could be considered as a feature to be included in future updates to the TCF infrastructure.
Is there any way for the signal of “legitimate interest” to be assessed by the IAB Europe Transparency and Consent Framework or will the signal be accepted as it was sent by the CMP?
Signaling of a ‘legitimate interest’ legal basis through the daisybit has been explored by the technical working groups. They determined at the time that the daisybit payload would be overloaded with this extra bit of information since it would effectively double the size. In turn this would add latency and mix intended signals in the Framework.
The Global Vendor List allows a vendor to declare their purposes and legal bases. The consent string should contain information about the user’s consent preferences, and separately, the pubvendors.json file can contain information about the publisher’s permissions for vendors, and for their vendor’s legal bases.
We are still exploring ways to consolidate all the information about whether the user’s data can be processed in future, but with the current iteration we have to rely on a solution which has a consent string on the one hand, and uses pubvendors.json to declare the reliance on legitimate interest on the other.
Is there a published technology roadmap? Is there going to be a defined update/release cycle for enhancements?
There are currently a few new feature updates that are being prioritized, and shared publicly, including pubvendors.json v1.1 finalization, adding security/authentication to the Framework, and efficiency updates. Members of the IAB Tech Lab GDPR working groups have full access to backlog and detailed roadmap of proposed features.
There seem to be many “private CMPs” who have not obtained their own CMP ID and are generating and transmitting consent strings with the invalid CMP id or 1 (what’s in the IAB source code”. Is there any effort underway to eliminate these invalid consent sources?
We have partnered with The Media Trust, who are developing a self-testing tool for CMPs to assess whether their CMP implementation is compliant with the policies of the IAB Europe Transparency and Consent Framework. This will allow current CMPs to improve their products to better fit the standards. This is the first step in a larger effort to validating CMPs, and in that process, we will more diligently update the list of CMPs on www.advertisingconsent.eu, including delisting CMPs that are found to be operating in a non-compliant way.
It should also be noted that, as a matter of the policies, vendors who receive a daisybit from an invalid CMP ID are required to ignore the signal and not act any further on the bid request it is appended to.