Downloaded 70 times
![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
}
]
}](https://image.slidesharecdn.com/11-180529162644/75/Interact-2018-IAB-Europe-s-GDPR-Transparency-Consent-Framework-26-2048.jpg)
![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
}
]
}](https://image.slidesharecdn.com/11-180529162644/75/Interact-2018-IAB-Europe-s-GDPR-Transparency-Consent-Framework-27-2048.jpg)
![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
}
]](https://image.slidesharecdn.com/11-180529162644/75/Interact-2018-IAB-Europe-s-GDPR-Transparency-Consent-Framework-28-2048.jpg)
Uploaded byIAB Europe
Interact 2018 - IAB Europe’s GDPR Transparency & Consent Framework
The document outlines a technical standard for enhancing digital advertising transparency and consent under EU regulations, focusing on issues related to GDPR and ePrivacy compliance. It proposes a flexible framework for managing data flows, consent management, and vendor transparency, aiming to minimize data leakage and facilitate easier compliance for publishers and advertisers. Key components include a global vendor list, the 'pubvendors.json' file for publishers to control vendor access, and standardized consent mechanisms to improve user experience and accountability in data handling.
More Related Content
Similar to Interact 2018 - IAB Europe’s GDPR Transparency & Consent Framework
Interact 2018 - IAB Europe’s GDPR Transparency & Consent Framework
- 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 RegulatoryChallenges •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 allabout 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 ofControl 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 dataleakage • 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 forConsumers 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 & ConsentFramework
- 10. Technical Context Industry Vendor List Vendorand 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-widelist 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 RequestingConsent • 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 customUI NB: Graphics are for illustration purposes only. 14 Level 1: Simple consent collection for all selected vendors and purposes
- 15. Example of customUI NB: Graphics are for illustration purposes only. 15 Level 2: Purpose-level consent options for consumers
- 16. Example of customUI NB: Graphics are for illustration purposes only. 16 Level 3: Vendor-level consent options for consumers
- 17. Storing Vendor andConsent 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 Vendorsand 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 astandard 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 • Outof 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 • placea 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 • Canbe 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) • disableUpstreamVendorsdisables 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) • Updateto 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) • Changeto 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.0is 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.