Fork<a href="/InteractiveAdvertisingBureau/GDPR-Transparency-and-Consent-Framework/network/members" class="social-count"aria-label="139 users forked this repository">
139
</a>

<h1 class="public ">InteractiveAdvertisingBureau / GDPR-Transparency-and-Consent-Framework</div>

Tree: 414b8e2373<div class="BtnGroup float-right"><a href="/InteractiveAdvertisingBureau/GDPR-Transparency-and-Consent-Framework/find/414b8e23737209f37c018611
af299003d167a270"
class="js-pjax-capture-input btn btn-sm BtnGroup-item"
data-pjax
data-hotkey="t">Find file</a><clipboard-copy for="blob-path" class="btn btn-sm BtnGroup-item">
Copy path</clipboard-copy></div><div id="blob-path" class="breadcrumb"><span class="repo-root js-repo-root"><span class="js-path-segment"><a data-pjax="true" rel="nofollow" href="/InteractiveAdvertisingBureau/GDPR-Transparency-and-Consent-Framework/tree/414b8e23737209f37c018611af299003d167a270"><span>GDPR-Transparency-and-Consent-Framework</span></a></span></span><span class="separator">/</span><strong class="final-path">pubvendors.json v1.0 Draft for Public Comment.md</strong></div></div>

jenniferIAB <a data-pjax="true" title="pubvendors.json spec for public comment

414b8e2 May 2, 2018

pubvendors.json v1.0 Draft for Public Comment until June 1 2018" class="message" href="/InteractiveAdvertisingBureau/GDPR-Transparency-and-ConsentFramework/commit/414b8e23737209f37c018611af299003d167a270">pubvendors.json spec for public comment<div class="commit-tease-contributors">

Details</div><div class="file ">316 lines (188 sloc)

22 KB

pubvendors.json v1.0: Transparency & Consent FrameworkIAB Europe | IAB Tech Lab
Draft for Public Comment | May 2018?. Introduction
Table of Contents
B. About the Transparency & Consent Framework
J. About the Transparency & Consent Standard
L. License
N. Disclaimer
O. About IAB Tech Lab
P. About IAB Europe

f. Overview
g. High Level Goals?i. Addressing Publisher Concerns??. Liability?B. Disagreement over Legal Basis (Legitimate Interest vs Consent)?J. Legitimate Interest?L. Technical Implementation?N. Publisher Integration?O. CMP Integration?P. SSP/DSP Integraation?f. Pubvendors.json version 1.0?g. Filename and Location
Bi. Format
B?. Looking forward: pubvendors.json v1.1
BB. Pubvendors.json v1.1 Updates
BJ. Global Vendor List Updates
BL. Expanded Purposes Controls
BN. Change to Consent String Protocol
BO. FAQ

IntroductionIn February 2017, the IAB Europe assembled parties representing both the supply and demand sides of thedigital advertising ecosystem, to work collectively on guidance and solutions to the requirements of theGeneral Data Protection Regulation (GDPR). That working group is known as the GDPR Implementation Working Group(GIG). One of the sub-groups within the GIG was tasked with developing guidance on consent as a legal basis forprocessing personal data. Out of that effort, an additional working group was formed to develop a technical solution to thechallenge of obtaining and disseminating consumer consent to the various parties relying on it as a legal basis ofprocessing personal data.
This specification "pubvendors.json" is a draft for public comment. Please submit your general feedback to
feedback@advertisingconsent.eu and any technical feedback to transparencyframework@iabtechlab.com by June 1, 2018.

About the Transparency & Consent Framework
The scope of the technical working group?s initiative increased to include a technical industry solution to allow website
operators to:?. Control the vendors they wish to allow to access their users? browsers (for setting and reading cookies) and process
their personal data and disclose these choices to other parties in the online advertising ecosystem
B. Seek user consent under the ePrivacy Directive (for setting cookies or similar technical applications that accessinformation on a device) and/or the GDPR in line with applicable legal requirements and signal the consent statusthrough the online advertising ecosystem
In summary, have one place to go to:Understand privacy-related disclosures about those vendors
Use those disclosures to make privacy-related disclosures to its users
Disseminate the disclosure status through the online advertising ecosystem.
The various pieces of the Framework are the following:A Global Vendor and CMP List (commonly referred to as the List)
The technical specification for capturing, storing and retrieving user consent in the context of digital advertising
Policy underlying the:Disclosures to be made by vendors included on the List
Use of the List and the reference architecture

About the Transparency & Consent Standard
Resources including policy FAQ, Global Vendor List Registration, and CMP registration can be found atadvertisingconsent.eu.
For purposes of this documentation, the following terms have the following definitions:"CMP" means a company that can read the vendors chosen by a website operator and the consent status of an end
user (either service specific (through a first-party cookie) or global (through a third-party cookie). A CMP is notsynonymous with a company that surfaces the user interface to a user (although it can be the same).
"Purposes" mean the purposes for which a Controller enabled by a website operator is using personal data collectedfrom (or received by a third party) about an end user.
"Daisybit" means information compressed into a binary value and passed throughout the online advertising
ecosystem through the OpenRTB specification.
"Vendor" means a third party that a website operator is using in connection with surfacing content to its end usersthat either (1) accesses an end user?s device or browser; and/or (2) collects or receives personal data about thewebsite operator?s end users. As such, a vendor need not be a Controller.

LicenseCopyright 2018 IAB Technology Laboratory
Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associateddocumentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights touse, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons towhom the Software is furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in all copies or substantial portions of the
Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT
LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM,DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT
OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

Disclaimer

THE STANDARDS, THE SPECIFICATIONS, THE MEASUREMENT GUIDELINES, AND ANY OTHER MATERIALS OR SERVICESPROVIDED TO OR USED BY YOU HEREUNDER (THE "PRODUCTS AND SERVICES") ARE PROVIDED ?AS IS? AND ?AS
AVAILABLE,? AND IAB TECHNOLOGY LABORATORY, INC. (?TECH LAB?) MAKES NO WARRANTY WITH RESPECT TO THE
SAME AND HEREBY DISCLAIMS ANY AND ALL EXPRESS, IMPLIED, OR STATUTORY WARRANTIES, INCLUDING, WITHOUT
LIMITATION, ANY WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, AVAILABILITY, ERRORFREE OR UNINTERRUPTED OPERATION, AND ANY WARRANTIES ARISING FROM A COURSE OF DEALING, COURSE OFPERFORMANCE, OR USAGE OF TRADE. TO THE EXTENT THAT TECH LAB MAY NOT AS A MATTER OF APPLICABLE LAWDISCLAIM ANY IMPLIED WARRANTY, THE SCOPE AND DURATION OF SUCH WARRANTY WILL BE THE MINIMUMPERMITTED UNDER SUCH LAW. THE PRODUCTS AND SERVICES DO NOT CONSTITUTE BUSINESS OR LEGAL ADVICE.
TECH LAB DOES NOT WARRANT THAT THE PRODUCTS AND SERVICES PROVIDED TO OR USED BY YOU HEREUNDERSHALL CAUSE YOU AND/OR YOUR PRODUCTS OR SERVICES TO BE IN COMPLIANCE WITH ANY APPLICABLE LAWS,REGULATIONS, OR SELF-REGULATORY FRAMEWORKS, AND YOU ARE SOLELY RESPONSIBLE FOR COMPLIANCE WITH
THE SAME.

About IAB Tech Lab
The IAB Technology Laboratory (?Tech Lab?) is a non-profit research and development consortium that produces andprovides standards, software, and services to drive growth of an effective and sustainable global digital media ecosystem.
Comprised of digital publishers and ad technology firms, as well as marketers, agencies, and other companies withinterests in the interactive marketing arena, IAB Tech Lab aims to enable brand and media growth via a transparent, safe,
effective supply chain, simpler and more consistent measurement, and better advertising experiences for consumers, witha focus on mobile and ?TV?/digital video channel enablement. The IAB Tech Lab portfolio includes the DigiTrust real-timestandardized identity service designed to improve the digital experience for consumers, publishers, advertisers, and thirdparty platforms. Board members include AppNexus, ExtremeReach, Google, GroupM, Hearst Digital Media, Integral Ad
Science, Index Exchange, LinkedIn, MediaMath, Microsoft, Moat, Pandora, PubMatic, Quantcast, Telaria, The Trade Desk,
and Yahoo! Japan. Established in 2014, the IAB Tech Lab is headquartered in New York City with an office in San Francisco
and representation in Seattle and London.
Learn more about IAB Tech Lab here: https://www.iabtechlab.com/

About IAB Europe
IAB Europe is the voice of digital business and the leading European-level industry association for the interactive
advertising ecosystem. Its mission is to promote the development of this innovative sector by shaping the regulatoryenvironment, investing in research and education, and developing and facilitating the uptake of business standards.
Learn more about IAB Europe here: https://www.iabeurope.eu/

Pubvendors.json Overview

High level goals

The high level goals of "pubvendors.json" supports the following:?. Provide a standard for publishers to publicly declare the vendors that they are working with and theirpermissions/configuration
B. Allow vendors to verify publisher GDPR settings and verify andaudit CMP consent string
J. Provide a standard way for publishers to whitelist vendors
L. Enable publishers to limit purposes on a per vendor basis
N. Enable publishers to limit features on a per vendor basis

Publishers concerns about IAB?s GDPR Transparency & Consent Framework
version 1.1
As understood by IAB Europe Transparency and Consent Steering Group and IAB Tech Lab GDPR Commit Group, thefollowing are the core publisher concerns:

Liability
Transparency and consent may not be seen as valid when many vendors and purposes are indiscriminately surfaced
without regard for limiting purposes per vendor
Indiscriminate rights for vendors:
Surfacing thousands of vendors with broad rights to use data w/out tailoring those rights may be too many
vendors/permissions
Concern that even if a user consents to vendors or doesn?t opt out of a vendor?s processing and broad purposes
where the vendor asks a user to, a user may not fully understand what it was told/consented to and publishers
may be found to have not done a good enough job limiting the further use of that data for broader arguably moreprivacy-intrusive uses
Ideally, publishers would be able to pick a small subset of vendors to which they give broader rights ("tier 1") andthen limit the rights of the rest of their vendors (?tier 2?) since publishers recognize that delivering ads to theirusers,either through direct online deals or programmatically, requires more vendors than those in ?tier 1?
Publishers recognize there is no technical way to limit the way data is used after the data is received by a vendor
for decisioning/bidding on/after delivery of an ad but need a way to clearly signal the restriction for permitted
uses in an auditable way
Thus, publishers need a way to differentiate between those 2 tiers of vendors in what they surface to a user andin what they signal to vendors on page and downstream and upstream through creatives and need to have anaudit trail to show thisControl of purpose and data use by vendor. Publishers and vendors need a signal to communicate to the vendors,
purposes and legal bases that have been disclosed on a publisher?s site. Publishers control the disclosures to theirusers and therefore which vendors can lawfully process the data of users visiting their properties
For example vendor 1 has permission for purposes 1, 2 and 3 but vendor 2 only has permission for purpose 3 only
Example uses publishers may wish to control:use of a user?s data processed through the delivery, or measurement, of an advertisement or the opportunity
to deliver, or measure, of an advertisement to inform future personalisation for such user based on
preferences or interests known or inferred from the data collected (inferences about a user can be
aggregated across sites)

Disagreement over legal basis (LI vs. consent)
A publisher may disagree with a vendor?s legal analysis on which legal basis the vendor can rely upon for a defined
purposePublishers can?t dictate the legal basis on which a vendor (that?s a controller) relies (that?s a legal analysis that has
to be made by each controller)
But Publishers can, based on the legal bases disclosed by a vendor for each purpose (registered in the global vendor
list), either choose not to work with that vendor or allow vendors which use one or other legal basis ( LI or consent)Given technical feasibility of publishers signalling information about the disclosures they have made on behalf of avendor, it is further possible for publishers to choose from several available legal bases that a vendor is willing to rely
on. For example, a vendor may be willing to operate on the basis of either user consent if a publisher is willing toobtain it, or justify processing under a legitimate interest in cases where a publisher is not willing obtaining consent fora given vendor.

Legitimate Interest
Framework must support vendors relying on LI and support publishers that only want to work with vendors relying on LI
Vendors can declare legal basis per purpose
LI status per vendor per purpose needs to be communicated to vendors downstream,so vendors know who is relying
on LITechnical implementationMaintain current technical specification (daisybit which communicates user consent per
purpose, where a vendor needs consent)
Add an out-of-band signal ("pubvendors.json" file a publisher places on each site) that publishers use to signal thefollowing to vendors:
Limitations that a publisher places on specific vendors by purpose.
Disclosures made by the publisher on behalf of the vendor, i.e. whether a publisher has disclosed a specificvendor as seeking consent or relying no a legitimate interest by purpose. This would also enable a publisher tosignal that a specific purpose has not been disclosed on behalf of a vendor.
Users would be able to consent/approve specific purposes and specific vendors. Publishers may provide additional
information to users, such as information that the publisher has imposed additional restrictions on certain vendors andtheir ability to collect data about a user on its site. The publisher may also provide information to the user about which
additional limitations apply to each vendor (for example: Vendor 25 may not process data for Personalization, i.e.
enhancing profiles, even though the user consented to that Purpose in general)
Vendors would crawl for "pubvendors.json" periodically. In future revisions the Daisybit will signal to vendors when a new ?
pubvendors.json? is available and possibly the content as well.

Publisher integration
A publisher would place a file named "pubvendors.json" at the ".well-known path" of their domain at: ?
http://publisher.com/.well-known/pubvendors.json? similar to ads.txt and robots.txt (https://tools.ietf.org/html/rfc5785).
The publisher should use a CMP that supports ?pubvendors.json?.
"pubvendors.json" may HTTP redirect (3xx) up to 5 hops (http://www.ietf.org/rfc/rfc1945.txt), anything beyond this may betreated as if the file is not present.

CMP integration
The CMP should check use the "pubvendors.json" as the base ruleset for what vendors to show to end clients and how todisplay them. The CMP should first check for the existence of the ?pubvendors.json?, if found the CMP should use therules defined for notification to the end user, otherwise global consent or CMP specific configuration can be assumed.

SSP/DSP integration

An SSP/DSP only needs to support version 1.0 of the spec if they are interested in supporting legitimate interest. The
GDPR Consent String contains a more restrictive set of information and downstream parties are compliant if they follow
approved vendor/purposes in the protocol.
If an SSP/DSP does want to support vendors relying on legitimate interest they can use "pubvendors.json" as an out ofband solution to augment the Consent String. The vendor needs to build a system to crawl for the existence of the filebuilding a database mapping between the publisher?s domain and rules/content within the file. If a publisher whitelists a
vendor claiming legitimate interest then Legitimate Interest can take precedence over the information in the Consent
String. The SSP/DSP should regularly sync the ?pubvendors.json? rules in order to stay up to date with publisher changes.

Pubvendors.json Version 1.0This is a simplified version of the original "pubvendors.json" spec targeted for use by
May 25th. Version 1.0 primary purpose to to achieve the following:?. Provide a standard way for publishers to declare a whitelist of vendors that they are working with.
B. Enabling vendors to rely on Legitimate Interest if the vendor is listed in the whitelist.
J. Work within the confines of the existing Version 1.1 of the IAB Europe Transparency and Consent Frameworkspecifications without modifications.
Version 1.0 requires no changes to the Global Vendor List or Version 1.1of the IAB Europe Transparency and Consent
Framework. Publishers will need to use a CMP that will support version 1.0 of the specification.

Filename and location"http://publisher.com/.well-known/pubvendors.json"

Format{"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},{"id": 2},{"id": 3}]}Future directions: pubvendors.json Version 1.1
Going forward, and building on the foundations of pubvendors.json Version 1.0, the proposed updates would be made to
the pubvendors.json specification, creating a pubvendors.json v1.1.

pubvendors.json Updates
disableUpstreamVendors publishers can choose to not pull in additional vendors from the global vendor list. This
would make the vendor list operate as a strict whitelist.

vendors.purposes publishers can restrict purposes by vendors{"publisherVendorsVersion": 1,"version": 1,"globalVendorListVersion": 1,"updatedAt": "2018-05-28T00:00:00Z","disableUpstreamVendors": true,"vendors": [{"id": 1,
"purposes": [1, 2, 3],// [Required] Version of the pubvendors.json specification// [Required] Increment on each update// [Required] The version of the GVL this was created from// [Required] Updated for every modification// [Optional] dont pull additional vendors from the GVL// [Required] Whitelist vendors// [Required] ID of vendor// [Optional] Publishers can restrict purposes by vendor},{"id": 2},{"id": 3}]}Global Vendor List updatesExpanded Purposes Controls
vendors.purposes.id - The id of the purpose. This should reference the purposes id field
vendors.purposes.legalBasis - The legal basis for which the vendor uses the purposes. This can either be "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.

"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},]

Change to Consent String protocol
The Consent String should be modified to pass the version of the pubvendors.json used when sending the request. The
value 0 would indicate that pubvendors.json is not present. The file version can be used by downstream parties todetermine if they have an up to date version of the file when processing requests.

FAQ

Why does this spec not address the Consent String?

We could expand the consent string to support Legitimate Interest in the future. The idea behind "pubvendors.json" goesbeyond the consent protocol, as a separate signal. We are simply suggesting starting with ?pubvendors.json? as a firststep, to allow for continued adoption of the Consent String v1.1 specification before May 25th.

How do publishers create a list of their vendors?
The goal of pubvendors.json is to publicly identify direct data processing relationships between publishers and adtechnology providers. As such publishers should identify all DSPs, SSPs and DMPs who they have an agreement with toprocess data. Additionally this should include any partners who you feel comfortable gaining consent on their behalf. This
list should include: programmatic partners and any third-party data providers you utilize to help build audience segments.
This may exclude downstream third parties who you do not feel comfortable authorizing consent as their legal basis fordata collection of your users.
As needed, Additional guidance will be created by the IAB Tech Lab GDPR working group.

</div></div>

<script crossorigin="anonymous" integrity="sha512-xx5bFEpCTis78HDM45zXGUp0XjJNgfxVJuvXT7CCXCTv1JgICExLtsUhV7HO90M3gLO0j5DA0zkAmM
rsLJsFUw==" type="application/javascript" src="https://github.githubassets.com/assets/frameworks-dcdc6bbaaa9ce93ccc296c33ff1f40c
3.js"></script><script crossorigin="anonymous" async="async" integrity="sha512-OVom1EjMVGuAhxgj+IUZGLWX+Y2YCwA5HczPO5EkywA3LpBr+opzeA2g7YZmzT0T
R0w94V9UGCvzNux1BO80gw==" type="application/javascript" src="https://github.githubassets.com/assets/github-ff2a16ee220770be00aef
7ab3773f297.js"></script>