Issue 402 #416
Issue 402 #416
Conversation
…-Transparency-and-Consent-Framework
| ## Additional clarification on using the GDPR_CONSENT_XXXX macro<a name="gdpr_consent_macro"></a> | ||
| ### Role of the vendor ID in the consent macro | ||
| The numeric Vendor ID of the vendor receiving the TC string must be included in consent macro because personal data (such as IP addresses or cookies) may be passed along with the request. The Vendor ID should be used by the service making the call to ensure they can verify their legal basis for processing. | ||
| The vendor ID macro is used in the case where the consent string cannot be obtained on the web page (no JS script available). In this case the consent macro will be in the form of ${GDPR_CONSENT_XXXX}, where XXXX is the numeric Vendor ID of the vendor receiving the TC string. The vendor encoded in this macro is then required to obtain the TC string and replace the gdpr_consent with the actual TC string (see [Transparency and Consent String with Global Vendor & CMP List Format](https://github.com/InteractiveAdvertisingBureau/GDPR-Transparency-and-Consent-Framework/blob/master/TCFv2/IAB%20Tech%20Lab%20-%20Consent%20string%20and%20vendor%20list%20formats%20v2.md#how-does-a-url-based-service-process-the-tc-string-when-it-cant-execute-javascript)). |
There was a problem hiding this comment.
I am a bit confused with this sentence: "The vendor encoded in this macro is then required to obtain the TC string and replace the gdpr_consent with the actual TC string"
by "vendor encoded in this macro" do we mean vendor XXX from macro ${GDPR_CONSENT_XXX} ? If so, he is not the one to obtain and replace the TC string. The vendor that will be initiating this call (the DSP / Adserver making redirect creative to that endpoint) will be the one replacing the macro by the TCS, and ensuring that vendor XXX has a legal base established if he intends to send him PD.
There was a problem hiding this comment.
I revised this and the other paragraphs in a new change list. Please review and if needed we can make more revisions to it.
| The vendor ID macro is used in the case where the consent string cannot be obtained on the web page (no JS script available). In this case the consent macro will be in the form of ${GDPR_CONSENT_XXXX}, where XXXX is the numeric Vendor ID of the vendor to receive the TC string. The service making the call will verify the legal basis for the vendor and will pass the TC string to the vendor in its return call (see [Transparency and Consent String with Global Vendor & CMP List Format](https://github.com/InteractiveAdvertisingBureau/GDPR-Transparency-and-Consent-Framework/blob/master/TCFv2/IAB%20Tech%20Lab%20-%20Consent%20string%20and%20vendor%20list%20formats%20v2.md#how-does-a-url-based-service-process-the-tc-string-when-it-cant-execute-javascript)). | ||
|
|
||
| ### Proper handling of vendor IDs in piggybacking scenarios | ||
| When a redirect is added to the pixel that means a new vendor will receive the request and that new vendor will need to resolve the consent string. There are two options here: |
There was a problem hiding this comment.
I am still a bit confused about this section. I don't really understand the two cases you mention.
I think another way to think of this is, that when a vendor XXX (receiving vendor) expects another vendor (initiating vendor) to call him and not have js access to fetch the TCS from the CMP directly (which can be either because he has a html only tag, or he is being called server side), the vendor XXX should include its ${GDPR_CONSENT_XXX} macro in his url, where he expects the initiating vendor to pass him the TCS. the XXX allow the initiating vendor to easily know who is the receiving vendor and what to look for in TCS before forwarding any PD.
In case of a vendor 123 (initiating) calling vendor 456 (intermediary receiving and then becoming initiating) calling himself another vendor 789 (receving only), then it should looks something like this:
vendor 789 expects vendor 456 to call him. Therefore, he sends him the url to call him on, which includes its GDPR macro ${GDPR_CONSENT_789}. That way, when calling him, vendor 456 knows where to put the TCS and know what checks to perform before including any PD in the call to vendor 789 (example of url: vendor789.domain.com/tag?gdpr_consent=${GDPR_CONSENT_789}&pd=PD_TO_BE_INCLUDED_IF_CONSENT)
Vendor 456 also sends vendor 123 the url to call him on, including where to include the TCS with its macro ${GDPR_CONSENT_456}, allowing vendor 123 to easily know where to put the TCS and know what checks to perform before including any PD in the call to vendor 789. ((example of url: vendor456.domain.com/tag?gdpr_consent=${GDPR_CONSENT_456}&pd=PD_TO_BE_INCLUDED_IF_CONSENT)
At time of the delivery, vendor 123 will receive the TCS, either from fetching it from the CMP API, or from receiving it in an openrtb bid request. He will checks for vendor 456 legal base, and based on check results, will include PD. He will also replace the GDPR_CONSENT_456 macro by the actual TCS and make the call to vendor456.domain.com/tag?gdpr_consent=ACTUAL_TCS&pd=123. Vendor 456 receiving the call will perform his data processing, then execute the vendor 789 piggyback pixel. He will check the legal base of vendor 789 in the TCS, then replace the GDPR_CONSENT_789 macro by the TCS and making call to the url vendor789.domain.com/tag?gdpr_consent=ACTUAL_TCS&pd=432.
From the above example, I don't understand why we need to have differentiated scenario for piggyback pixel. The receiving vendor is the one responsible to indicate to calling vendor if he needs him to forward him the TCS. In case the GDPR_CONSENT_XXX macro is missing, it means the receiving vendor expects to be able to determine consent on its own (through fetching the TCS from the CMP API for example), in which case the initiating vendor doesn't need to include the TCS. The initiating vendors may still try to identify the receiving vendor by different means (since he doesn't have the vendor id in the macro) to perform checks on its own
There was a problem hiding this comment.
Thanks again for the guidance here. I be frank, I never had to use these macros and never fully understood how this should be used in some of these use cases. Again thanks for your patience in explaining this to me. Created a new revision of these paragraphs using some of your explainations.
|
@lamrowena Can you please review this as well. Thanks! |
addresses issue 402