search

IABTechLab / iabgpp-es

Apache License 2.0
24 stars 8 forks source link

Other regulation GVL support #51

Open sevriugin opened 4 months ago

sevriugin commented 4 months ago

Are we going to support GVLs for different regulations in the library? For example IAB Canada GVL for tcfca ?

HeinzBaumann commented 4 months ago

Yes, Canada has a separate GVL from Europe. EU: https://vendor-list.consensu.org/v3/vendor-list.json Canada: https://vendor-list.consensu.org/v2/ca/vendor-list.json

sevriugin commented 4 months ago

@HeinzBaumann thanks, so we need to have update GPP lib logic to make it multi-GVL ready. Maybe, I am not sure, but API need to be updated also as now these two guys (see the snippet) looks very IAB TCF EU GVL specific:

getGvlFromVendorList(vendorList: VendorList): GVL
async getGvlFromUrl(gvlUrlConfig: GVLUrlConfig): Promise<GVL>
sevriugin commented 4 months ago

Another question regarding US regulations and vendors. No vendors related signals in US segments (sub-strings) are present, is it correct? The vendors are related ONLY to tcfeuv2 and tcfcav1, right?

HeinzBaumann commented 4 months ago

As far as I know, yes, so far vendor signals only apply to tcfeuv2 and tcfcav1.

HeinzBaumann commented 4 months ago

@HeinzBaumann thanks, so we need to have update GPP lib logic to make it multi-GVL ready. Maybe, I am not sure, but API need to be updated also as now these two guys (see the snippet) looks very IAB TCF EU GVL specific:

getGvlFromVendorList(vendorList: VendorList): GVL
async getGvlFromUrl(gvlUrlConfig: GVLUrlConfig): Promise<GVL>

The format and mechanism to retrieve the GVL is the same between EU and Canada. But in a GPP it require to cache both at the same time. So I would think spoec and library will need to account for this.

sevriugin commented 4 months ago

Yes, we could update GVL type to make it more genetic and include Canada specific fields like impConsPurposes, but it will create a mess that it's difficult to manage and support.

For example now GPP GVL still has TCF v2 properties like policyUrl (optional) that need to be deprecated and urls also optional that must be present for TCF v2.2. It will be better to have separate types like EuGVL and CaGVL and then GVL = EuGVL | CaGVL if needed.

The other problem with VendorList interface that also need to be regulation specific under the hood as now it holds Vendor form EuGVL.

So, maybe it will be easier to have regulation specific functions, like 

getEuGvlFromVendorList(vendorList: EuVendorList): EuGVL 
async getEuGvlFromUrl(gvlUrlConfig: GVLUrlConfig): Promise<EuGVL>

What do you think @HeinzBaumann

HeinzBaumann commented 4 months ago

Yes, we could update GVL type to make it more genetic and include Canada specific fields like impConsPurposes, but it will create a mess that it's difficult to manage and support.

For example now GPP GVL still has TCF v2 properties like policyUrl (optional) that need to be deprecated and urls also optional that must be present for TCF v2.2. It will be better to have separate types like EuGVL and CaGVL and then GVL = EuGVL | CaGVL if needed.

The other problem with VendorList interface that also need to be regulation specific under the hood as now it holds Vendor form EuGVL.

So, maybe it will be easier to have regulation specific functions, like

getEuGvlFromVendorList(vendorList: EuVendorList): EuGVL 
async getEuGvlFromUrl(gvlUrlConfig: GVLUrlConfig): Promise<EuGVL>

What do you think @HeinzBaumann

That works for me.