Permalink
771 lines (646 sloc) 36.1 KB

Consent String and Vendor List Format: Transparency & Consent Framework

IAB Europe | IAB Tech Lab

Final v1.1 | April 2018

Table of Contents

  1. Introduction
  2. About the Transparency & Consent Framework
  3. About the Transparency & Consent Standard
  4. License
  5. Disclaimer
  6. About IAB Tech Lab
  7. About IAB Europe
  8. Consent String and Vendor List Format v1.1
  9. Version History
  10. In the GDPR Global DaisyBit consent solution, what purpose does the consent string serve?
  11. What information is stored in the consent string?
  12. What is not being supported in the consent string format?
  13. What is contained in the vendor list JSON?
  14. What are the URLs for the vendor (and standard purposes lists?
  15. What is the process of getting on the global vendor list?
  16. What is the format of the global vendor (and standard purposes) list?
  17. What are the purposes and features being supported?
  18. What are the fields of the global vendor consent cookie?
  19. Vendor Consent String Format
  20. Example Vendor Consent String
  21. How is publisher-specific consent stored?
  22. Publisher Purposes Consent String Format
  23. Major changes

Introduction

In February 2017, the IAB Europe assembled parties representing both the supply and demand sides of the digital advertising ecosystem, to work collectively on guidance and solutions to the requirements of the General 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 for processing personal data. Out of that effort, an additional working group was formed to develop a technical solution to the challenge of obtaining and disseminating consumer consent to the various parties relying on it as a legal basis of processing personal data.

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:

  1. 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
  2. Seek user consent under the ePrivacy Directive (for setting cookies or similar technical applications that access information on a device) and/or the GDPR in line with applicable legal requirements and signal the consent status through 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 at advertisingconsent.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 not synonymous 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 collected from (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 users that either (1) accesses an end user's device or browser; and/or (2) collects or receives personal data about the website operator's end users. As such, a vendor need not be a Controller.

License

Copyright 2018 IAB Technology Laboratory

Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom 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 SERVICES PROVIDED 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, ERROR-FREE OR UNINTERRUPTED OPERATION, AND ANY WARRANTIES ARISING FROM A COURSE OF DEALING, COURSE OF PERFORMANCE, OR USAGE OF TRADE. TO THE EXTENT THAT TECH LAB MAY NOT AS A MATTER OF APPLICABLE LAW DISCLAIM ANY IMPLIED WARRANTY, THE SCOPE AND DURATION OF SUCH WARRANTY WILL BE THE MINIMUM PERMITTED 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 HEREUNDER SHALL 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 and provides 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 with interests 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, with a focus on mobile and "TV"/digital video channel enablement. The IAB Tech Lab portfolio includes the DigiTrust real-time standardized identity service designed to improve the digital experience for consumers, publishers, advertisers, and third-party 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 regulatory environment, investing in research and education, and developing and facilitating the uptake of business standards.

Learn more about IAB Europe here: https://www.iabeurope.eu/

Consent string and vendor list format v1.1

Version History

2018/04/24 - Version 1.1 final publication

2018/03/08 - Version 1.1 published for 30-day public comment

2017/12/19 - Initial version v1.0 created

In the GDPR Global DaisyBit consent solution, what purpose does the consent string serve?

After the interaction between an end user and the Consent Manager Provider (CMP) UI, the consent info is stored (for example, as a third-party cookie) in the user's browser. The data in the consent string answers the question: "Which vendors and purposes did the user give consent for?"

What information is stored in the consent string?

The data stored in the consent string is divided into 3 parts:

  1. Metadata of the consent info, e.g. consent string version, when updated, vendor list version, what compression scheme applied on the data.

  2. What standard purposes (not per-vendor) the user has given consent for (See Policy FAQ).

  3. What vendors the user gave consent to.

What is not being supported in the consent string format?

  • Multiple vendor lists support (or regional lists)

  • Intelligent handling of deleted vendors

  • Distinct recording of "Consent Revoked" (as opposed to "No Consent")

  • "Not yet consented" state per vendor (it's either "Consent" or "No Consent", or string-not-present).

  • Legal audit trail within the consent string. However, the following details are stored for consent logging and audit record: LastUpdated, CmpId, CmpVersion, ConsentScreen, ConsentLanguage, and VendorListVersion.

What is contained in the vendor list JSON?

  • A vendor list version

  • A list of standard purposes (identifies PurposesAllowed and StandardPurposesAllowed consent bits) (See Policy FAQ for definitions.)

  • A list of standard features. Vendors can indicate that they use features. Since they span data purposes, they are not individually consentable-to by the user, but should be shown in the vendor details in the UI.

  • A list of vendors with assigned VendorIds, the standard purposes they are requesting consent for, the standard purposes they will be using legitimate interest for, and the URL of their GDPR policy page. VendorIds are incrementally-assigned and never reused; deleted vendors are just marked as deleted.

What are the URLs for the vendor (and standard purposes) lists?

The vendor list will be in JSON and hosted at https://vendorlist.consensu.org/vendorlist.json . Previous and the current version are available at https://vendorlist.consensu.org/v-versionnum/vendorlist.json , where versionnum is a decimal number from 0 to 4095 as indicated in the VendorListVersion field.

Translations of the standard purposes' names and descriptions to non-English languages will be contained in a JSON file including only the 'purposes', 'features', 'vendorListVersion', and 'lastUpdated' keys, and hosted at https://vendorlist.consensu.org/purposes-language.json with older versions at https://vendorlist.consensu.org/v-*versionnum*/purposes-language.json where language is the two-letter lowercase ISO 639-1 language code.

What is the URL for Vendor Info (ad serving and asset domains for vendors in the GVL)?

The Vendor Info file will be in JSON and hosted at https://vendorlist.consensu.org/vendorinfo.json.

In this file, the use of the term "AdServers" is representative of the type of domains associated with a vendor that would be used in delivery of assets or script on page, including (but not limited to) ad serving domains.

What is the format for Vendor Info JSON File?

{
	"vendorListVersion": 36,
	"lastUpdated": "2018-05-30T16:10:05Z",
	"vendors": [
 {
		"id": 1,
		"name": "Example Company",
		"AdServers": ["example.company.com (Description, Ad server and tracker)", 
  }
  .... and so on for each vendor included in the Global Vendor List
}

What is the process of getting on the global vendor list?

Access http://advertisingconsent.eu/ to register on the global vendor list. Registration guidelines are available on this website as well.

What is the format of the global vendor (and standard purposes) list?

Purposes, features, and vendors will be sorted by "id".

The JSON format is:

{
  "vendorListVersion": 0, // will be incremented each change*
  "lastUpdated": "2018-05-28T00:00:00Z",
  "purposes": [
    { 
      "id": 1,
      "name": "Storage and access of information",
      "description": "The storage of information, or access to information that is already stored, on user device such as accessing advertising identifiers and/or other device identifiers, and/or using cookies or similar technologies.."
    },
    // ... more purposes from id=2 to currently, id=5 (max, id=24)
  ],
  "features" : [
    {
      "id": 1
      "name": "Matching Data to Offline Sources",
      "description": "combining data from offline sources that were initially collected in other contexts"
    },
    // ... more purposes from id=2 up to no higher than id=64. Currently there are 3 planned features*
  ],
  "vendors": [
    {
      "id": 1,
      "name": "Vendor Name",
      "purposeIds": [1], // list of consentable data purposes
      "legIntPurposeIds": [2, 3], // list of (non-consentable) data purposes that will be used under legitimate interest
      "featureIds": [1, 2], // list of features
      "policyUrl": "[https://vendorname.com/gdpr.html](https://vendorname.com/gdpr.html)",
      "deletedDate": "2018-05-28T00:00:00Z", // if present, vendor should be considered deleted after this date/time
    },
    // ... more vendors, expecting several hundred vendors in the initial Global Vendor List*
  ]
}

What are the purposes and features being supported?

The entries below are valid for the v1.1 release. Purposes and features are subject to change, so are included in the Global Vendor List. For most up-to-date policy defined purposes, please refer to http://advertisingconsent.eu/#resources.

Purposes are individually-consentable data uses. Due to space constraints in the consent string, they are not consentable on a per-vendor basis, but which vendors utilize which purpose should be shown in the UI for each vendor. Consent for a purpose applies only to vendors that have declared (via the Global Vendor List) that they use that purpose.

Features are informational and should be shown on the UI as a data use by that vendor for transparency purposes, but since they can span multiple (consentable) purposes, they are not individually consentable.

purpose number purpose name purpose description
1 Storage and access of information The storage of information, or access to information that is already stored, on user device such as accessing advertising identifiers and/or other device identifiers, and/or using cookies or similar technologies.
2 Personalisation The collection and processing of information about user of a site to subsequently personalize advertising for them in other contexts, i.e. on other sites or apps, over time. Typically, the content of the site or app is used to make inferences about user interests, which inform future selections.
3 Ad selection, reporting and delivery The collection of information and combination with previously collected information, to select and deliver advertisements and to measure the delivery and effectiveness of such advertisements. This includes using previously collected information about user interests to select ads, processing data about what advertisements were shown, how often they were shown, when and where they were shown, and whether they took any action related to the advertisement, including for example clicking an ad or making a purchase.
4 Content delivery, selection and reporting The collection of information, and combination with previously collected information, to select and deliver content and to measure the delivery and effectiveness of such content. This includes using previously collected information about user interests to select content, processing data about what content was shown, how often or how long it was shown, when and where it was shown, and whether they took any action related to the content, including for example clicking on content.
5 Measurement The collection of information about user use of content, and combination with previously collected information, used to measure, understand, and report on user usage of content.
feature number feature name feature description
1 Matching Data to Offline Sources combining data from offline sources that were initially collected in other contexts
2 Linking Devices allow processing of a user's data to connect such user across multiple devices.
3 Precise Geographic Location Data allow processing of a user's precise geographic location data in support of a purpose for which that certain third party has consent.

What are the fields of the global vendor consent cookie?

Cookie Directive Value(s) Notes
Name euconsent
Host .consensu.org The DNS resolution for the name cmp-name.mgr.consensu.org will be delegated by the standardizing authority (IAB) to each CMP. CMPs will host their code, APIs, and CDN at this domain or subdomains.
Path /
Max-Age 33696000 This represents thirteen 30-day months.
Value base64url-encoding of the concatenated Cookie Value Fields bits described below. Padding '=' characters should be omitted. The binary bits should be padded at the end with zeroes to the nearest multiple of 8 bits, packed into a string of bytes, and have base64url-encoding performed.

Vendor Consent String Format

The following fields are stored in big-endian format. Example values are provided below, and bit numberings are left-to-right.

Vendor Consent String Field Name Number of bits (bit offsets) Value(s) Notes
Version 6 bits (0-5) "1" for this version Incremented when consent string format changes
Created 36 bits (6-41) Epoch deciseconds when consent string was first created Deciseconds fits into 36 bits with enough precision to record a user's consent action timing. Javascript: Math.round((new Date()).getTime()/100)
LastUpdated 36 bits (42-77) Epoch deciseconds when consent string was last updated
CmpId 12 bits (78-89) Consent Manager Provider ID that last updated the consent string A unique ID will be assigned to each Consent Manager Provider
CmpVersion 12 bits (90-101) Consent Manager Provider version Each change to the CMP should receive a new version number, for logging proof of consent
ConsentScreen 6 bits (102-107) Screen number in the CMP where consent was given The screen number is CMP and CmpVersion specific, and is for logging proof of consent
ConsentLanguage 12 bits (108-119) Two-letter ISO639-1 language code that CMP asked for consent in Each letter should be encoded as 6 bits, A=0..Z=25 . This will result in the base64url-encoded bytes spelling out the language code (in uppercase).
VendorListVersion 12 bits (120-131) Version of vendor list used in most recent consent string update. Vendor list versions will be released periodically. 12 bits allows for 78 years of weekly updates.
PurposesAllowed 24 bits (132-155) For each Purpose, one bit: 0=No Consent 1=Consent Purposes are listed in the global Vendor List. Resultant consent value is the "AND" of the applicable bit(s) from this field and a vendor's specific consent bit. Purpose #1 maps to the first (most significant) bit, purpose #24 maps to the last (least significant) bit.
Above fields are multiples of 6 bits to fit into base64url-encoded bytes.
MaxVendorId 16 bits (156-171) The maximum VendorId for which consent values are given. VendorIds are numbered 1 to MaxVendorId. Allows the consent string to be interpreted without waiting for the vendor list fetch.
EncodingType 1 bit (172) 0=BitField 1=Range The consent encoding used. Either a BitFieldSection or RangeSection follows. Consent string encoding logic should choose the encoding that results in the smaller output.
BitFieldSection Encodes one consent bit per VendorId
BitField MaxVendorId bits (173-...) For each Vendor, one bit: 0=No Consent 1=Consent The consent value for each VendorId from 1 to MaxVendorId
RangeSection Encodes a default consent value and any number of single or range override entries
DefaultConsent 1 bit (173) 0=No Consent 1=Consent Default consent for VendorIds not covered by a RangeEntry. VendorIds covered by a RangeEntry have a consent value the opposite of DefaultConsent.
NumEntries 12 bits (174-185) Number of entries to follow NumEntries instances of RangeEntry follow.
RangeEntry (repeated NumEntries times, indicated by [idx]) A single or range of VendorIds, whose consent value is the opposite of DefaultConsent. All VendorIds must be between 1 and MaxVendorId.
SingleOrRange[idx] 1 bit 0=Single VendorId 1=VendorId range Whether a single VendorId or a start/end range of VendorIds is given
SingleVendorId[idx] 16 bits A single VendorId. Exclusive with Start/EndVendorId.
StartVendorId[idx] 16 bits The start of an inclusive range of VendorIds Exclusive with SingleVendorId. Must be paired with a EndVendorId
EndVendorId[idx] 16 bits The end of an inclusive range of VendorIds Exclusive with SingleVendorId. Must be paired with a StartVendorId.

Example Vendor Consent String

Example consent string field values for the case:

  • all VendorId consents given, except VendorId=9

  • for VendorListVersion=8 which has 2011 VendorIds defined

  • by Consent Manager Provider Id #7

Field Decimal Value Meaning Binary Value
Version 1 Consent String Format Version #1 000001
Created 15100821554 2017-11-07T19:15:55.4Z 001110000100000101000100000000110010
LastUpdated 15100821554 2017-11-07T19:15:55.4Z 001110000100000101000100000000110010
CmpId 7 The ID assigned to the CMP 000000000111
CmpVersion 1 Consent Manager Provider version for logging 000000000001
ConsentScreen 3 Screen number in the CMP where consent was given 000011
ConsentLanguage "EN" (E=4, N=13) Two-letter ISO639-1 language code that CMP asked for consent in 000100 001101
VendorListVersion 8 The vendor list version at the time this consent string value was set 000000001000
PurposesAllowed 14680064 Purposes #1, 2, and 3 are allowed 111000000000000000000000
MaxVendorId 2011 Number of VendorIds in that vendor list 0000011111011011
EncodingType 1 Range encoding (not bitfield) 1
DefaultConsent 1 Default is "Consent" 1
NumEntries 1 One "range or single" entry 000000000001
SingleOrRange[0] 0 A single VendorId (which is "No Consent") 0
SingleVendorId[0] 9 VendorId=9 has No Consent (opposite of Default Consent) 0000000000001001
fillbits The binary bits should be padded at the end with zeroes to the nearest multiple of 8 bits 00000

Concatenated cookie value field bits

The complete byte-oriented consent string representation for the previously shown example is:

00000100 11100001 00000101 00010000 00001100 10001110
00010000 01010001 00000000 11001000 00000001 11000000
00000100 00110001 00001101 00000000 10001110 00000000
00000000 00000000 01111101 10111100 00000000 01000000
00000001 00100000 00000000

Building the Base64 representation

This string is built using the base64url-encoded representation of the concatenated Cookie Value Fields bits described earlier. Attention: Padding '=' characters should be omitted.

The calculated value for this example is:

BOEFEAyOEFEAyAHABDENAI4AAAB9vABAASA

How is publisher-specific consent stored?

Under this proposal, there are two types of publisher-specific consent: service-specific vendor consent, and a publisher's purposes consent for its own data use (if needed). For example, a publisher that wants to set a frequency-capping first-party cookie should request Publisher Purposes Consent for Purpose #1 "Accessing a Device".

Service-specific vendor consent can be implemented (optionally) by a CMP using the same Vendor Consent String Format (as detailed above) with the Host, Path, and/or Cookie Name referencing a first-party cookie (or service-shared 3rd-party cookie). If a CMP allows a subset of vendors to be configured by a publisher, storage of consent in a service-specific cookie is necessary to avoid clearing previously-given consent (on non-included vendors) on the global cookie.

The following table indicates which fields are used by which cookie:

Consent String Format Type Cookie Location Purpose
Vendor Consent 3rd-party global location (.consensu.org). Required cookie name: euconsent global vendor consent
Vendor Consent 1st-party publisher-configured name & location. Could instead be a 3rd-party shared location, for a service-specific cookie that spans publisher sites. Recommended default cookie name: euconsent service-specific vendor consent
Publisher Purposes Consent 1st-party publisher-configured name & location (again, could be a shared 3rd-party location as well). Recommended default cookie name: eupubconsent publisher's own data usages consent (not looked at by vendors)

A publisher's purposes consent string stores the publisher's own consent. This is different than the consent string used to collect consumer consent for vendors. The publisher can configure the CMP to request consent for any of the standard list of purposes (which utilizes the StandardPurposesAllowed bitfield and the standard list of purposes from the Vendor List) and/or custom purposes (initialized by the publisher).

Differences from the Vendor Consent String Format are:

  • "PublisherPurposesVersion" augments "VendorListVersion" and is incremented each time the publisher modifies the requested purposes.

  • "NumCustomPurposes" replaces "MaxVendorId" and is reduced to 6 bits.

  • "BitField" encoding is always used and is indexed by CustomPurposeId's.

  • Host, Path, and Cookie Name are configured in the CMP by the publisher, and the consent string data is stored as a first-party cookie by the CMP javascript.

Publisher Purposes Consent String Format

The following fields are stored in big-endian format, the binary bits padded at the end with zeroes to the nearest multiple of 8 bits, packed into a string of bytes, and base64url-encoding performed (with '=' padding omitted).

Publisher Purposes Consent String Field Name Number of bits (bit offsets) Value(s) Notes
Version 6 bits (0-5) "1" for this version Incremented when consent string format changes
Created 36 bits (6-41) Epoch deciseconds when consent string value was first created Deciseconds fits into 36 bits with enough precision to record a user's consent action timing. Javascript: Math.round((new Date()).getTime()/100)
LastUpdated 36 bits (42-77) Epoch deciseconds when consent string value was last updated
CmpId 12 bits (78-89) Consent Manager Provider ID that last updated the consent string value A unique ID will be assigned to each Consent Manager Provider
CmpVersion 12 bits (90-101) Consent Manager Provider version Each change to the CMP should receive a new version number, for logging proof of consent
ConsentScreen 6 bits (102-107) Screen number in the CMP where consent was given The screen number is CMP and CmpVersion specific, and is for logging proof of consent
ConsentLanguage 12 bits (108-119) Two-letter ISO639-1 language code that CMP asked for consent in Each letter should be encoded as 6 bits, a=0..z=25 . This will result in the base64url-encoded bytes spelling out the language code (in uppercase).
VendorListVersion 12 bits (120-131) Version of vendor list used in most recent consent string value update. The vendor list provides the list of standard purposes, so the version of the vendor list used is recorded.
PublisherPurposesVersion 12 bits (132-143) Version of publisher purposes list used in most recent consent string value update. Publishers initialize the CMP with this version, and should increment it for any changes to the list of requested purposes so that consent can be re-obtained.
StandardPurposesAllowed 24 bits (144-167) For each standard purpose, one bit: 0=No Consent 1=Consent Standard purposes are listed in the global Vendor List.
NumberCustomPurposes 6 bits (168-173) The number of custom purposes consent bits. CustomPurposeIds are numbered 1 to NumberCustomPurposes. Custom purposes will be initialized in the CMP by the publisher.
Above fields are multiples of 6 bits to fit into base64url-encoded bytes.
CustomPurposesBitField NumberCustomPurposes bits (174-...) For each custom purpose, one bit: 0=No Consent 1=Consent The consent value for each CustomPurposeId from 1 to NumberCustomPurposes

Major changes from v1.0

  • 2018-03-20 Features added to vendorlist

  • 2018-03-22 "Consent Cookie" wording and title changed to "Consent String" in all places not specifically referring to a cookie

  • 2018-03-22 legitimate interest purposes supported (per vendor) with legIntPurposeIds

  • 2018-03-27 added recommended cookie names for publisher-local cookies

  • 2018-04-02 change purposes[].purpose to purposes[].name for consistency

  • 2018-04-09 Changed CmpVersion from 6 to 12 bits