Held in Milan on 23-24 May, IAB Europe’s annual 2-day conference Interact 2018 featured a training by Wilfried Schobeiri, Chief Technology Officer, MediaMath and Matthias Matthiesen, Director Public Policy & Privacy IAB Europe Following up on the plenary session from DAY 1 on IAB Europe’s GDPR Transparency & Consent Framework this training session presented by IAB Europe will offer the opportunity to ask any questions you may still have regarding the implementation of the Framework from the Global Vendor List to ensuring the best possible User Experience.

1. DIGITAL ADVERTISING
TRANSPARENCY, CONTROL, CONSENT
Interact 2018
May 24th
Technical standard in
development and
subject to change.
1
Presented by:
Wil Schobeiri, CTO, MediaMath
Matthias Matthiesen, Director, Privacy &
Public Policy at IAB Europe

2. Agenda
•Issue: EU Regulatory Challenges
•Solutions
•Closed Ecosystem
•Open Framework within an independent and flexible ecosystem
•Standard Framework
•Goals
•Framework
•Technology
•Pubvendors.json
2

3. AdTech Data Flows… Sell-side
3
DATA
SUBJECT
PERSONAL DATA
• IDFA
• advertising ID
• cookies/unique identifier
• lat/long
• IP Address
• segments
S2S SERVER
Cookie Synching
On Page Header
Bidding Partners
Third parties and
advertisers collecting
data re: ad delivery,
conversion and
attribution
Header Bidding
Demand Partners
External Bidders
Real Time Data
Providers
Subcontractors
PUBLISHERS
ADVERTISER
*Data flows are an example for illustrative purposes only, certain data flows may be missing or different for different parties
SSP

4. AdTech Data Flows… Buy-side
4
DATA
SUBJECT
DIRECT
RETAILER
ADVERTISER
LANDING PAGE
CRM
Onboarder
ADVERTISER
AD SERVER
ADVERTISER
DSP
*Data flows are an example for illustrative purposes only, certain data flows may be missing or different for different parties
SSP

5. It’s not all about Consent
• Under GDPR, consent is only one of six “legal grounds” for
processing personal data, and therefore not always needed
• For the purposes of access and storage of information on
devices ePrivacy Directive consent requirements currently
apply
• The Framework is designed to be flexible and accommodate
different publisher and vendor needs centering on
transparency, control and choice
5

6. Data leakage
Lack of Control and Transparency over partners and demand sources on page (and their
partners)
No single privacy policy
ePrivacy
GDPR requirements
Continued monetization
Current Challenges
6

7. Benefits
• Control data leakage
• Single privacy policy
• Easier consent
• Easier GDPR compliance
Closed Ecosystem
Challenges
• Control of data and reporting
• Control of third party partners
• Control of demand
7

8. Standard Framework
Transparency for Consumers and Publishers into partners that help monetize sites and apps
Control for Publishers over partners operating on sites and apps and processing their users’
data
Control for Consumers over how their personal data is used and by which partners
Consent as a potential legal basis
Standardization allowing publishers and partners to operate and communicate efficiently using
a single, open source standard
Flexibility for publishers and demand sources to build or work with various consent
management providers
Minimize Disruption of the Internet, benefiting consumers, publishers & supporting companies
8

9. Transparency & Consent Framework

10. Technical Context
Industry
Vendor List
Vendor and
Consent
Storage and
Transmission
Publisher
Header Tag
Exchanges
DSP
DSP
DSP
CProposal
Publisher
Ad Server
DSP /
DMP
Dynamic
Creative
Server
Fully
Customizable
Consent UI
10

11. The Technology
1. Industry-wide list of vendors bound to standard protocols and
policies (Publisher choice over which vendors to activate)
2. Standardized mechanism for requesting, storing, and
optionally sharing approved vendors and consent
• Standard JS API
• Standard vendor/consent storage format (currently 1st/3rd party
cookies)
• Standardized data structure for transmitting vendor/consent state
3. Open source specification, complete with reference
implementations
11

12. Global Vendor List
• A centralized, dynamic list of
vendors, their purposes, their
privacy policy URL, et al
• Versioned to allow for audit trail
• Publishers will use the global
vendor list as basis for disclosure
and consent requests
• Both vendors and publishers will
need to adhere to baseline
principles and minimum
standards
ID Company Privacy Policy Purposes …
1 SSP1 ssp1.de/privacy 1, 2, 3 …
2 ANW2 anw2.be/privacy 2, 3 …
3 ANA5 ana5.fi/privacy 4 …
… … … … …
ID Purpose Description … …
1 Purpose 1 domain.eu/purpose/1 … …
2 Purpose 2 domain.eu/purpose/2 … …
3 Purpose 3 domain.eu/purpose/3 … …
… … … … …
12

13. Providing Transparency and
Requesting Consent
• A JavaScript library/API which enables publishers to customize
the experience of providing transparency disclosures and
requesting consent
• Abstracts the complexities of consent checking and storage
• Implements standardized minimum disclosure language
• Ensures the vendor list and disclosure language stays updated to latest
version
• Integrates with consent identification mechanism
• Makes approved vendor and consent data available for downstream
usage via daisy chain
13

14. Example of custom UI
NB: Graphics are for illustration purposes only. 14
Level 1:
Simple consent
collection for all
selected
vendors and
purposes

15. Example of custom UI
NB: Graphics are for illustration purposes only. 15
Level 2:
Purpose-level
consent options
for consumers

16. Example of custom UI
NB: Graphics are for illustration purposes only. 16
Level 3:
Vendor-level
consent options
for consumers

17. Storing Vendor and Consent Signals
• Approved Vendor and Consent storage requires two mechanisms: a user identification method and
persistence method.
• Identification method
• The identification needed for global consent to be made possible could be done via multiple
mechanisms (e.g., id syncing).
• Implementation to be determined by the publisher and vendor. API will standardize interaction, not
implementation.
• Persistence method
• Multiple storage options possible: cookie, mobile app SDK, login alliances, centralized registries, etc.
• Javascript library gives vendors the flexibility to implement storage in whatever mechanism they see fit,
supporting both desktop and mobile
17

18. Transmitting Approved Vendors and
Consent
• Consent value to be binary
• Consent values to be compressed into as small of a data structure possible.
• Consent data structure is flexible
• Policy requirements and technical feasibility will determine final implementation.
• Consent transmitted via a Daisy Chain
• every upstream member will append a consent payload to all downstream
requests.
• OpenRTB to directly support consent transmission
18

19. 1. ✓ SSP1
2. ✓ SSP2
3. ✓ Exchange1
4. X Exchange2
5. ✓ Exchange3
6. ✓ DMP1
7. ✓ DMP2
8. ✓ DMP3
9. ✓ DMP4
10. X DMP5
11. X DMP6
12. ✓ DPM7
13. X DMP8
14. ✓ DMP9
15. X DSP1
16. X DSP2
17. ✓ DSP3
18. ✓ DSP4
19. X DSP5
20. X DSP6
1. ✓ PURP1
2. ✓ PURP2
3. ✓ PURP3
4. ✓ PURP4
5. ✓ PURP5
11111 1110111110010100110011011111001010110
Purpose
Choices
String
Vendor
Choices
String
Purpose
Choices
Vendor
Choices
P
U
R
P
1
P
U
R
P
5
D
M
P
2
D
S
P
7
3FDF299BE572
21. ✓ DSP7
22. ✓ DSP8
23. X DSP9
24. ✓ DCO1
25. ✓ DCO2
26. ✓ DCO3
27. ✓ DCO4
28. ✓ DCO5
29. X DCO6
30. X DCO7
31. ✓ DCO8
32 X DCO9
33. ✓ Viewability1
34. X Viewability2
35. ✓ Viewability3
36. ✓ Viewability4
37. ✓ Viewability5
38. X Viewability6
39. X Viewability7
40. ✓ Viewability8
41. X Viewability9
Compressed
Value
Encoding Choices for Storage &
Transmission
19

20. 3FDF299BE572
Consent Payload: “3FDF299BE572” appended to every request
Transmitting Approved Vendors
and Consent
PublisherPublisher
Publisher
Ad Server
DMP1
SSP1
SSP2
Exchange1
Exchange2
Exchange3
DSP5
DSP1
Advertiser
Ad Server
DCO1
Viewability
1
Advertiser
Ad Server
DCO5
Viewability
5
DSP9
Advertiser
Ad Server
DCO9
Viewability
9
DSP8
Advertiser
Ad Server
DCO8
Viewability
8
DSP7
Advertiser
Ad Server
DCO7
Viewability
7
DSP6
Advertiser
Ad Server
DCO6
Viewability
6
DSP3
DSP4
DSP2
Advertiser
Ad Server
DCO2
Viewability
2
Advertiser
Ad Server
DCO3
Viewability
3
Advertiser
Ad Server
DCO4
Viewability
4
DMP
2
DMP
3
DMP
5
DMP
4
DMP
8
DMP
9
DMP
7
DMP
6
3FDF299BE572
3FDF299BE572
3FDF299BE572
Has consent
Doesn’t have consent
20

21. Combined, they enable...
• Control over the vendors enabled by publishers.
• Transparency into the supply chain for consumers &
publishers.
• An auditable consent trail that gives all supply chain
members confidence by providing a more efficient disclosure
mechanism, enabling companies to ”know” rather than
“assume” their consent status with a user.
• A better user experience than if every publisher were to try
to solve the challenge on their own.
21

22. Problem: Publisher’s Liability
• Publishers have approached the IAB for a solution that will
allow them to protect themselves and their customers from
exposure to vendors that the publisher doesn’t do business
with.
• They also asked for a way to configure purposes per vendors
and have a control of the vendors listed in the consent UI.
22

23. Goal
• Provide a standard for publishers to publicly declare the
vendors that they are working with and their
permissions/configuration
• Allow vendors to verify publisher GDPR settings and verify
and audit CMP consent string
• Provide a standard way for publishers to whitelist vendors
• Enable publishers to limit purposes on a per vendor basis
• Enable publishers to limit features on a per vendor basis
This configuration is an optional feature to the IAB’s T&C
framework.
23

24. Solution: pubvendors.json
• Out of band signal ("pubvendors.json") to signal to vendors
and CMPs:
• Limitations that a publisher places on specific vendors by purpose
• Disclosures made by the publisher on behalf of the vendor
• Vendor crawl for the pubvendors.json periodically
24

25. Integration:
• Publisher
• place a pubvendors.json file at the ".well-known path" of their domain:
http://publisher.com/.well-known/pubvendors.json
• CMP
• Check for pubvendors.json file on the publisher “.well-known path”
and uses this to filter the list of vendors to present to the user.
• SSP/DSP:
• Can use "pubvendors.json" as an out of band solution to augment the
Consent String by crawling the publisher’s site.
25

26. Pubvendors.json v1.0
• Can be used immediately by Publishers to signal to the CMP
which vendors to present to the user.
• Enabling vendors to rely on legitimate interest
26
{
"publisherVendorsVersion": 1, // [Required] Version of the
pubvendors.json specification
"version": 1, // [Required] Increment on
each update of this file
"globalVendorListVersion": 1, // [Required] The version of the GVL this
was created from
"updatedAt": "2018-05-28T00:00:00Z", // [Required] Updated for every modification
"vendors": [ // [Required] Whitelist vendors
{
"id": 1 // [Required] ID of vendor from GVL
},
{
"id": 2
}
]
}

27. Pubvendors.json v1.1(proposal)
• disableUpstreamVendors disables to pull in additional vendors
from the global vendor list.
• vendors.purposes allows restrict purposes by vendors
27
{
"publisherVendorsVersion": 1, // [Required] Version of the
pubvendors.json specification
"version": 1, // [Required] Increment on
each update of this file
"globalVendorListVersion": 1, // [Required] The version of the GVL this
was created from
"updatedAt": "2018-05-28T00:00:00Z", // [Required] Updated for every modification
"disableUpstreamVendors": true, // [Optional] dont pull additional vendors from the GVL
"vendors": [ // [Required] Whitelist vendors
{
"id": 1 // [Required] ID of vendor from GVL
"purposes": [1, 2, 3], // [Optional] Publishers can restrict purposes by vendor
},
{
"id": 2
}
]
}

28. Pubvendors.json v1.1(proposal)
• Update to the GVL to expand purpose control
• vendors.purposes.id - The id of the purpose from the GVL.
• vendors.purposes.legalBasis - The legal basis for which the vendor
uses the purposes. (either "consent" or “legitimateInterest”)
• vendors.purposes.required - An optional field that signals to external
parties if a specific purpose is required for a vendor to operate.
28
"purposes": [
{
"id": 1, // [Required] ID of purpose
"legalBasis": "consent|legitimateInterest", // [Required] legal basis for usage of purpose
"required": boolean, // [Optional] Is this purpose a requirement
for the
// vendor to operate
}
]

29. Pubvendors.json v1.1(proposal)
• Change to Consent String protocol
• The Consent String should be modified to pass the version of the
pubvendors.json used when sending the request. 0 = that
pubvendors.json was not present.
• The file version can be used by downstream parties to determine if
they have an up to date version of the file when processing requests.
29

30. Timeline
• pubvendors.json v1.0 is available for immediate use by CMPs
• pubvendors.json v1.1 spec is under review and open for public
comments. Review cycle end June 1st.
Link to spec:
https://github.com/InteractiveAdvertisingBureau/GDPR-
Transparency-and-Consent-
Framework/blob/master/pubvendors.json%20v1.0%20Draft%20f
or%20Public%20Comment.md
30

31. Stay informed
www.advertisingconsent.eu
31