CONSENT MANAGEMENT PROVIDERS (CMPs)
Companies operating as a CMP can read and/or set a user’s consent status for the vendors chosen by a website operator, either publisher specific, through a first-party cookie, or global, through a third-party cookie, and make this information available to a third-party that publishers choose to work with.
THE FRAMEWORK ENABLES CMPs TO:
- Provide transparency to a user into the vendors that a publisher has chosen to work with;
- Provide transparency into the purposes and legal basis that a vendor wishes to leverage – the 5 purposes’ names and descriptions can be found here
- Store a user’s consent signals, for example a third-party cookie, in the user’s browser and make consent information available to vendors in the consent string;
- Ensure that consent for a purpose applies only to the vendors that have declared, via the List, that they use that purpose;
- View vendor controller DNS hostnames, including AdServers, at https://vendorlist.consensu.org/vendorinfo.json.
A CMP is not necessarily synonymous with a company that surfaces the user interface to a user, although it can be the same.
FAQs: CONSENT MANAGEMENT PROVIDERS (CMPs) AND THE FRAMEWORK
- “Purposes” – the purposes for which a vendor enabled by a website operator is using personal data collected from, or received by a third-party, about an end user.
- “Vendor” – a third-party that a service operator is using in connection with surfacing content to its end users that either (1) access an end users’ device or browser for setting cookies, etc., or (2) collects personal data based on the actions of the service operator’s end users – vendor need not be a controller.
- “List” – Global Vendor & CMP List that contains the approved registration and allocation of vendor IDs and CMP sub-domains for global participation in the Framework.
1. Does the CMP need consent from the consumer to be a CMP?
No, the CMP will not necessarily need to have consent to set a cookie to capture and store consent state. We consider that setting a cookie to manage and respect a user’s choices as required by the law falls under a necessity exception.
Once the CMP has read and stored a user’s consent status it is important to understand how that consent status is handled.
2. What consent states are available?
There are two consent states in the protocol:
- No Consent (0), which could include new users who have not yet been asked for their consent, users who have said no, or users who have revoked consent
- Consent (1)
3. Are there other consent states that will not be transmitted as part of the Framework?
Possible consent states that will not be explicitly signalled include:
- Revoked – this can, however, be determined based on the audit trail held by the vendor. NOTE: Revocation is not the same as a user requesting right to access or deletion of data.
- New User – this can be determined by the absence of a stored consent signal.
4. Will a central entity host common revocation pages and what functionality would that revocation need to have?
Initially, CMPs and publishers will host their own revocation pages, and when consent is revoked, the consent status will be updated in the storage medium from 1 to 0.
5. How long is consent valid once it has been granted?
The lifespan of consent differs from case to case. Consistent with what regulatory authorities have interpreted to be a reasonable lifespan of a cookie under the ePrivacy Directive, as guidance, consent should be valid for 13 months before a refresh or reminder is recommended.
6. Should a vendor report to the CMP if it receives a consent or revocation signal directly?
Yes, vendors must report global consent changes to the CMP. Vendors should also report publisher-specific consent changes to the CMP if possible.
7. What is the standard logic to reconcile conflicting signals?
Publisher-specific consent status overrules a global consent status for that service. For example, a user gives global consent for data processing by a particular vendor on Site A. User then visits Site B and is prompted for publisher-specific consent and says no. Result: vendor has global consent except on Site B. When comparing two like signals, for example both conveying publisher-specific consent, then the signal with the most recent timestamp prevails. CMPs must resolve conflicts before transmitting any consent signal in the DaisyBit mechanism.
CONSENT STRING AND GLOBAL VENDOR LIST FORMAT SPEC V1.1
MOBILE IN-APP SPECIFICATION V1.0
IAB Europe Transparency and Consent Framework Implementation Guidelines
Register for our weekly webinars, taking place Fridays at 17:00 CEST.
View the upcoming schedule and register:
The registration process is open for vendors and CMPs to apply for approved status in the context of IAB Europe Transparency & Consent Framework.