add publisher string support and versioning

[Pernic]

I have created a object vendor consent string (who support versioning, encoding and decoding) and create the support of publisher consent string.

[visskiss]

The API for swift does not require creation of Consent Strings at the moment. Also this is a complete rewrite.

[jvdadda]

@visskiss Hi,

Why ? Generating a consent string on iOS is not allowed ? So, no CMP ? What is the purpose of reading a consent string if no-one can generate-it ?

Plus, others libraries have the support of generating the consent string (javascript, java)

I think that IAB needs to provide a supported way to generate a valid consent string

[visskiss]

The swift API as published by the IAB is the ConsentStringProtocol found in this repository. When the API changes, the protocol and implementation will follow.

[jvdadda]

Hi Visskiss,

Yeah, I understand, but in this case, you will not have differents versions support ? If a consent string v2 is published by IAB, you should be able to decode a consent string v1, no ?

And what about the encode feature ? Some CMP may want to use an open source library supported by IAB. And maybe update the Readme because it says that the library

can encode and decode consent strings

Thanks

[zahoork]

Hi Visskiss,
I completely agree with Jean (Jivyx), e.g. we the publishers(who act as CMP as well) would like to generate consent strings as well using this SDK (based on vendors list, purposes supported etc). Many publishers have raised this with IAB since the first day this SDK was released, otherwise this SDK is mainly useless if we have to rely on one more party SDK to generate the Consent Strings. Same changes were requested in IAB Java SDK and have been approved and implemented. In-fact now there is a discussion on how to support this for whole Android Eco-system.

Regards,
Zahoor

[visskiss]

Hi Zahoor,

The intent of the IAB from what I understand is that you should use the Consent Widget (I'm looking for a link) to manipulate the consent string. The Swift framework is really intended just for decoding. Why? Because the consent widget has access to the web and is viewed in a web view that allows access to the live json file. Doing the same thing across multiple frameworks was not the intent. As a CMP, you should be using that widget to perform the necessary functions of obtaining consent. This swift framework is intended to access the relevant values for publishers (and not CMP's). I understand where you are coming from. Is there any reason you are not using the consent widget?

[chrispaterson]

I originally wrote the API specification for all of the Consent String SDKs. There is no reason why we can't generate consent strings in the native layer if that's what is wanted. The specification was originally written without that ability because it seemed as if the IAB was going toward using a web view context with a JS CMP and passing information back to the native layer through "parsed consents". I am concerned with this pull request because of the "complete rewrite." What is the justification for that?

[Pernic]

the goal is to be able to use it in a native CMP.

[jdowd7]

Agree on @Pernic 's above- was under the impression that fully native SDK would be supported by the IAB.

@chrispaterson we need to integrate a node.js app in order to encode a consent string?