Other regulation GVL support

[sevriugin]

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

[HeinzBaumann]

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]

@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]

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]

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

[HeinzBaumann]

@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]

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]

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.