https://id.sharedid.org/id returns 204

[bjorn-lw]

The URL returns 204 only, not a user id.

There is no error response of any kind returned other than the 204 code so it's a bit difficult to figure out the reason for the endpoint not working.

The endpoint is called from Prebid.js (tested version 4.18.0).

A TCF2 CMP is active and consent data is properly passed to adapters, but I don't see it being used with any code related to sharedid.

[SKOCHERI]

https://id.sharedid.org/id throws 204 error when GDPR requirment is not met.
I believe you are trying from EU, can you try https://id.sharedid.org/id?gdrp=1&gdpr_consent=

In PrebidJS, the sharedId user id module needs to be updated to pass the GDPR param to the sharedid endpoint.

[bjorn-lw]

@SKOCHERI That's what I thought as well. I tried with a valid allow all consent string (including Rubicon) right now but still got 204. Tried setting GPPR=0, still 204. Using the exact URL you have above (with empty consent string), also 204.

Prebid.js doesn't seem to be adding any consent string to this endpoint. I guess we need to add code for that if the endpoint expects that, but first we need to prove it works even with a valid consent string.

Could you provide me with a consent string you know should work or let me know what should have consent?

Thanks!

[SKOCHERI]

Just to note the vendor in the consent string should be sharedId vendor 887.

[bjorn-lw]

Check this, please:

https://id.sharedid.org/id?gdrp=1&gdpr_consent=CPAU-t7PAU-t7AcABBENBLCsAP_AAH_AAChQHPNf_X_fb3_j-_59_9t0eY1f9_7_v-0zjgeds-8Nyd_X_L8X42M7vF36pq4KuR4Eu3LBIQdlHOHcTUmw6okVrTPsbk2Mr7NKJ7PEinMbe2dYGH9_n9XTuZKY79_s___z__-__v__7_f_r-3_3_vp9X---_e_UDnwCTDUvgIsxLHAkmjSqFECEK4kOgFABRQjC0TWEBK4KdlcBH6CBgAgNQEYEQIMQUYsAgAAAACSiICQA8EAiAIgEAAIAVICEABGgCCwAkDAIABQDQsAIoAhAkIMjgqOUwICJFooJ5KwBKLvYwwhDKLACgUf0VAAAAAA.YAAAAAAAAAAA

Content of consent string can be verified here: https://iabtcf.com/#/decode

887 should be there.

[SKOCHERI]

887 (Prebid.org ) is in the vendor list https://vendor-list.consensu.org/v2/vendor-list.json.

[bjorn-lw]

887 (Prebid.org ) is in the vendor list https://vendor-list.consensu.org/v2/vendor-list.json.

That’s great. And it should be represented in the consent string I sent but still no luck. Maybe you can send me a consent string that you know will work and I can try that?

[SKOCHERI]

I don't have one right now. Will try to construct one.

[bjorn-lw]

Thanks! ...and no rush. It’s getting late here so I’ll continue this tomorrow.

[SKOCHERI]

@bjorn-lw Can you try with "CPA-ieRPA-ieRABAMBENACBsAIEAAAAgEAYgG7wAQG7gbvACAAEA3cAA" . This consent string has grant for 887

[bjorn-lw]

Success! But the IAB consent string decoder complains that it's an invalid consent string:
TCModelError: invalid value 1 passed for cmpId

Maybe you just put a test value for the CMP that is not recognized as a valid CMP id and the rest is OK.

How did you generate the string? Are you sure it's a valid TCF2 string?

I'd like to find out how this string differs from the one I sent which had grant 887 as well (please have a look at my consent string if you can spot what's wrong with it).

[SKOCHERI]

https://github.com/InteractiveAdvertisingBureau/iabtcf-java I used the encoder to get the above consent string.

[bjorn-lw]

I ran it through my own decoder and it passes, I don't check if the CMP id is valid. So all good.

But do you know why the following consent string is not accepted by the endpoint (I know it's huge, but I picked it from an actual generated consent string from a live CMP)?

887 is granted.
Purpose 1 is granted
Special features opt in 1 is granted

CPAU-t7PAU-t7AcABBENBLCsAP_AAH_AAChQHPNf_X_fb3_j-_59_9t0eY1f9_7_v-0zjgeds-8Nyd_X_L8X42M7vF36pq4KuR4Eu3LBIQdlHOHcTUmw6okVrTPsbk2Mr7NKJ7PEinMbe2dYGH9_n9XTuZKY79_s___z__-__v__7_f_r-3_3_vp9X---_e_UDnwCTDUvgIsxLHAkmjSqFECEK4kOgFABRQjC0TWEBK4KdlcBH6CBgAgNQEYEQIMQUYsAgAAAACSiICQA8EAiAIgEAAIAVICEABGgCCwAkDAIABQDQsAIoAhAkIMjgqOUwICJFooJ5KwBKLvYwwhDKLACgUf0VAAAAAA.YAAAAAAAAAAA

[jdwieland8282]

Can you try it w/o the special features opt in? I believe we check for vendor 887 and purpose 1. I don't believe we check for special features and including it could invalidate the daisybit.

[dmdabbs]

Can you try it w/o the special features opt in? I believe we check for vendor 887 and purpose 1. I don't believe we check for special features and including it could invalidate the daisybit.

The Special Features are an essential part of the transparency/signaling so those two bits being on shouldn't 'invalidate' any tcstring.

[SKOCHERI]

@bjorn-lw The consent string you provided does not have vendor 887 in its vendor Legitimate Interest. These are the vendor legitimate interest from that consent string {8, 11, 14, 15, 20, 21, 23, 25, 28, 30, 31, 32, 33, 34, 42, 46, 48, 49, 52, 53, 57, 60, 62, 63, 67, 68, 69, 76, 79, 82, 85, 86, 88, 92, 93, 95, 98, 100, 102, 104, 109, 111, 115, 122, 127, 132, 134, 136, 137, 138, 142, 145, 150, 151, 152, 154, 163, 165, 177, 179, 183, 185, 190, 194, 195, 200, 202, 203, 205, 209, 212, 213, 215, 217, 218, 223, 231, 234, 236, 238, 239, 240, 246, 248, 251, 252, 253, 255, 256, 259, 261, 263, 264, 265, 273, 277, 278, 279, 280, 281, 282, 284, 290, 297, 298, 310, 318, 319, 321, 323, 331, 335, 336, 343, 347, 354, 360, 361, 365, 371, 373, 377, 378, 382, 384, 385, 394, 428, 431, 434, 436, 440, 444, 452, 455, 466, 467, 468, 469, 475, 484, 488, 498, 502, 511, 528, 539, 541, 543, 546, 554, 559, 573, 577, 578, 580, 590, 596, 598, 599, 610, 613, 620, 621, 630, 645, 647, 656, 657, 659, 664, 666, 667, 678, 682, 684, 694, 699, 706, 709, 714, 720, 721, 724, 728, 729, 730, 736, 738, 740, 744, 745, 746, 749, 751, 754, 755, 762, 770, 774, 777, 781, 783, 784, 786, 790, 792, 798, 801, 802, 803, 804, 807, 810, 812, 814, 815, 825, 828, 830, 834, 836, 837, 838, 840, 841, 842, 843, 845, 846, 850, 851, 856, 857, 862, 867, 872, 873, 876, 878, 882, 884, 885, 896, 898, 905, 907, 911, 912, 913, 914, 915, 916, 917, 919, 923, 925, 927}

[bjorn-lw]

@SKOCHERI

edit: my bad, you’re right. It’s not in the li list, I accidentally expanded the consent list. Not being an expert here, but if we have consent for purpose 1, would that not be enough?

_that’s interesting because that’s not what the IAB decoder says. I’ll try and run it through my own decoder to verify.

Can you verify it says the same result through https://iabtcf.com/#/decode?_

[SKOCHERI]

I don't see 887 even in the https://iabtcf.com/#/decodevendor legitimate interest

[bjorn-lw]

@SKOCHERI you’re right. See my edit above. But there’s still consent for purpose 1. I’m admittedly not an expert but shouldn’t that be enough?

[SKOCHERI]

Along with purpose 1, the vendor consent and vendor legitimate interest is required. @jdwieland8282 Please confirm.

[bjorn-lw]

Your vendor list entry doesn’t list any li purpose, only purposes (1) and specialfeatures (1)

[SKOCHERI]

Your vendor list entry doesn’t list any li purpose, only purposes (1) and specialfeatures (1)

You can try with this consent string CPBBm7KPBBm7KFmAMBENACBMAIEAAAAgEAYgG7wAQG7gbvACAAEA3cAA
which has valid Cmp Id, vendor consent and vendor LI.

[bjorn-lw]

@SKOCHERI I was referring to entry 887 here: https://vendor-list.consensu.org/v2/vendor-list.json

[SKOCHERI]

@jdwieland8282 Can you clarify on this one. Do we need to consider only purpose 1 and special feature as consent granted?

[dmdabbs]

One can only perform Purpose 1 (Store and Access Info on a Device), i.e. read/write cookies & storage, using consent legal basis.
So you want the following:
Purpose 1 consent signal on
Vendor 887 vendor consent bit on

That would be your minimum bar.

SharedID.org has only declared that it will perform Purpose 1

"887":{"id":887,"name":"Prebid.org","purposes":[1],"legIntPurposes":[],"flexiblePurposes":[],"specialPurposes":[],"features":[],"specialFeatures":[1],"policyUrl":"https://docs.prebid.org

It also has declared it may use Precise Geolocation. Not sure why that is, but it shouldn't apply to simply greocoding an IP and reading/writing a cookie.
cc: @jdwieland8282

[jdwieland8282]

We need both our (Mangite & Prebid)opinion is that Purpose 1 and a valid vendor gvlid are required, in this case 887.

It also has declared it may use Precise Geolocation. Not sure why that is, but it shouldn't apply to simply greocoding an IP and reading/writing a cookie.

@dmdabbs not sure I understand your question. We use geo detection to determine if the request is coming from an EEA country, we do not rely on the requestor to accurately declare whether or no GDPR applies using the gdpr=1|0 query param.

[bjorn-lw]

We need both our (Mangite & Prebid)opinion is that Purpose 1 and a valid vendor gvlid are required, in this case 887.

Sorry, I don't understand the sentence. Can you rephrase? :)

@dmdabbs not sure I understand your question. We use geo detection to determine if the request is coming from an EEA country, we do not rely on the requestor to accurately declare whether or no GDPR applies using the gdpr=1|0 query param.

How do you manage to get a precision of <500 m without getting actual geo data sent in the request?

[jdwieland8282]

Sorry, I don't understand the sentence. Can you rephrase? :)

purpose 1 and a valid gvlid are required.

Check out https://github.com/prebid/shared-id/blob/main/src/main/java/org/sharedid/endpoint/service/GeoIpService.java for the second part of your question. The short answer is we geo detect the requestors IP address using maxmind

[bjorn-lw]

purpose 1 and a valid gvlid are required.

Without a valid gvl id I don't see how you can verify purpose 1 and how the CMP would work in that case, but OK, that was the meaning of "both". We can then safely ignore the legitimate interest part that has been discussed previously, and the same there, I can't see how a CMP can set the legitimate interest consent for a vendor that hasn't listed any legitimate interest in the vendor-list.json. Do you agree with me on this?

Check out https://github.com/prebid/shared-id/blob/main/src/main/java/org/sharedid/endpoint/service/GeoIpService.java for the second part of your question. The short answer is we geo detect the requestors IP address using maxmind

I'm not sure this requires Special Feature 1 (precise geo location data) since the service only returns country/city/state which is clearly less precise than < 500 m radius unless details of the code escapes me (and you only look at country level, right?). It's still based on IP-address and while you can be lucky and get OK precision I don't think it's the case in general. However, it shouldn't matter much since the Special Feature 1 is set in the vendor-list.json and can then also be checked against when verifying consent.

[dmdabbs]

@jdwieland8282 said
@dmdabbs not sure I understand your question. We use geo detection to determine if the request is coming from an EEA country, we do not rely on the requestor to accurately declare whether or no GDPR applies using the gdpr=1|0 query param.
@bjorn-lw said
How do you manage to get a precision of <500 m without getting actual geo data sent in the request?

Align with Bjorn on the SF. That Special Feature declared by #887 (Prebid.org) is for establishing a legal basis to process precise geolocation, which as Bjorn points out is neither sent by the caller, shared in the response and probably not even used in the geocoding of the IP. I will try to make today's Identity PMC call if appropriate to discuss there.

Regarding vendor id, what processing SharedID/Prebid is performing and whether it's is a controller bear on that. Too much to get into here probably.

[jdwieland8282]

@bjorn-lw yes I agree. When vendor 887 was created it was not given the necessary permissions, apologies for that. We are going to fix that now. I will follow up once we have a solution.

Re: prebid/Prebid.js#6266

We would love some help making the suggested changes if you are up for it?

[bjorn-lw]

@bjorn-lw yes I agree. When vendor 887 was created it was not given the necessary permissions, apologies for that. We are going to fix that now. I will follow up once we have a solution.

Hey, no need to apologize :) This is quite tricky stuff or we wouldn't have had this lengthy discussion :)

Re: prebid/Prebid.js#6266

We would love some help making the suggested changes if you are up for it?

Yes, I will do. I am (as everyone else I guess) quite busy with tasks piling up, but at a quick look it seemed to be fairly simple to fix.

[jdwieland8282]

We have taken a closer look at what permissions vendor 887 has and concluded that 887 as created does have the correct permissions.

{
   "887":{
      "id":887,
      "name":"Prebid.org",
      "purposes":[
         1
      ],
      "legIntPurposes":[
         
      ],
      "flexiblePurposes":[
         
      ],
      "specialPurposes":[
         
      ],
      "features":[
         
      ],
      "specialFeatures":[
         1
      ],
      "policyUrl":"https://docs.prebid.org/privacy.html",
      "cookieMaxAgeSeconds":31536000,
      "usesNonCookieAccess":false
   }
}

Once prebid/Prebid.js#6275 is complete and merged GDPR params will be sent to the SharedId endpoint and syncing in the EEA will be possible.

[bjorn-lw]

@jdwieland8282 Sounds reasonable! You will need to change the code for verifying consent to NOT verify legitimateInterest grant as the CMP will not include 887 in the "Vendor Legitimate Interrests" list if legIntPurposes is empty in the vendor list for 887 as you have now decided it will continue to be.

[jdwieland8282]

Closing will track the fix in

#21

and

prebid/Prebid.js#6275