Wrong decoding of custom purposes on IAB TCF Code Library and CMP Validator

I’ve encoded a TCString including a PublisherTC segment with the following purposes:

• purpose 1 on consent
• purpose 5 on legitimate interest
• 2 custom purposes on consent
• 1 custom purpose on legitimate interest

Here is the TCString: COwnRWbOwnRZLBcABBENAdCsAP_AAH_AAAqIF0EWSQgCYWghI0QUBxBAIYAfJgSCAMgCAAQIoSgFQISERBAGKiAQHAEQJAAAGBAAEACAAQAgHGBMCQAAgAABiRCEQUGICzNIBIBAggEaYUFAAAVmGkHCmZCY70ywOmQLoIIEBAEAkABAIAADECAQwAQDAAAAYAkAAABAhIKAAgIiAAEcAAAAAAgAAAAAAABAAAAAAAAAICIAAABAAAgAiAAAAAAGgIQAACBAAAAQIAAAAANAAAAiCEAQgoEAIgAA.cAAAAQAAAeI

When encoding the TCString, I set the custom purposes fields as follows:

• NumCustomPurposes = 3
• CustomPurposesConsent = 110
• CustomPurposesLITransparency = 001

Through the API, our CMP surfaces the TCData object as expected:

But when I decode the TCString in the IAB TCF Code Library, the decoder doesn’t split the custom purposes in consent and legitimate interest. Instead of decoding 3 consents and 3 legitimate interests, the decoder interprets 6 consents.

The same problem occurs in the CMP Validator:

I think both tools need to take in consideration the NumCustomPurposes field to split the purposes.

Thanks

[chrispaterson]

Nice catch @laurent-chriqui, I had forgotten that those are viable length encodings. I’ll need to open a new issue to fix that.

[laurent-chriqui]

From what I have seen in the code: CustomPurposesConsent and CustomPurposesLITransparency have a bitlength of 24 instead of NumCustomPurposes

I think there was a mistake in this fix: https://github.com/InteractiveAdvertisingBureau/iabtcf-es/issues/52

publisherConsents was mistaken with the two fields afore mentionned which should not have a fixed bitlength.