Wildcard Publisher restriction #332
Open
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
janwinkler
approved these changes
Jan 9, 2023
achimschloss
suggested changes
Jan 12, 2023
Comment on lines
+214
to
+217
| - purpose ID 0 restriction type 1 | ||
| - purpose ID 0 restriction type 0 | ||
| - specific purpose ID restriction type 1 | ||
| - specific purpose ID restriction type 0 |
There was a problem hiding this comment.
Given we are in the descriptive segment it does seem hard to read as written (how would I know what a purpose 0 restriction is)
Suggested change
| - purpose ID 0 restriction type 1 | |
| - purpose ID 0 restriction type 0 | |
| - specific purpose ID restriction type 1 | |
| - specific purpose ID restriction type 0 | |
| - general restriction type 1 (require consent) | |
| - general restriction type 0 (not allowed) | |
| - specific purpose restriction type 1 (require consent) | |
| - specific purpose restriction type 0 (not allowed) |
| For example if the TC String includes 1) a restriction signal that specifies consent is applicable to the vendor for the processing for a specific purpose and 2) a restriction signal that disallows the vendor the processing for a specific purpose, the vendor must consider it is not allowed to engage in processing for this specific purpose irrespective of the consent signal. | ||
|
|
||
| If the TC String includes 1) a restriction signal that specifies consent is applicable to the vendor for the processing for a specific purpose and 2) a restriction signal that disallows the vendor the processing for the same purpose, the vendor must consider it is not allowed to engage in processing for this specific purpose irrespective of the consent signal. (pub restriction type 0 takes precedence over pub restriction type 1). | ||
|
|
There was a problem hiding this comment.
As suggested by Julien, would be good to have an example where a generel restriction overrules a specific one.
|
|
||
| In case a vendor has declared flexibility for a purpose and there is no legal basis restriction signal it must always apply the default legal basis under which the purpose was registered aside from being registered as flexible. That means if a vendor declared a purpose as legitimate interest and also declared that purpose as flexible it may not apply a "consent" signal without a legal basis restriction signal to require consent. | ||
|
|
||
| In case of conflicting publisher restrictions, vendors should respect the following hierarchy to determine if processing is permissible at all for a specific purpose or which legal basis is applicable (from lower priority to higher priority): |
There was a problem hiding this comment.
We should add language that CMP should avoid conflicting signals, but we would want to define rules to deal with them
Suggested change
| In case of conflicting publisher restrictions, vendors should respect the following hierarchy to determine if processing is permissible at all for a specific purpose or which legal basis is applicable (from lower priority to higher priority): | |
| CMPs should avoid to define conflicting publisher restrictions, specifically w.r.t. multiple restrictions on a specific purpose. In case conflicting publisher restrictions are present, vendors should respect the following hierarchy to determine if processing is permissible at all for a specific purpose or which legal basis is applicable (from lower priority to higher priority): |
| The Vendor’s declared Purpose ID that the publisher has indicated | ||
| that they are overriding. | ||
| <br><br> | ||
| When the value of PurposeID is set to 0 and the value of RestrictionType is <code>1</code>, the publisher has indicated they are overriding all TCF purposes to require Consent, including Special Purposes. In such a case, both Special Purposes are allocated the <b>ID 24</b> in the <code>PurposesConsent</code> field. |
There was a problem hiding this comment.
We should also add a hint on ID 24 in the PurposesConsent field description
Jaxs88
approved these changes
Jun 29, 2023
HeinzBaumann
requested changes
Nov 29, 2023
lucy-web-dev
approved these changes
Feb 4, 2025
lucy-web-dev
approved these changes
Feb 4, 2025
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.