# IAB TCF specifications: consent strings, CMP APIs and where the liability sits > The InteractiveAdvertisingBureau GDPR Transparency and Consent Framework repository is a document set rather than a codebase, holding the CMP JavaScript API, the consent string and vendor list formats, the mobile in-app API and the TCF v2 documents that ad technology vendors implement against. **InteractiveAdvertisingBureau/GDPR-Transparency-and-Consent-Framework** — Technical specifications for IAB Europe Transparency and Consent Framework that will help the digital advertising industry interpret and comply with EU rules on data protection and privacy - notably the General Data Protection Regulation (GDPR) that comes into effect on May 25, 2018. - Repository: https://github.com/InteractiveAdvertisingBureau/GDPR-Transparency-and-Consent-Framework - Stars: 953 · Forks: 371 - Language: Unknown - License: not declared - Published: 2026-10-20 · Updated: 2026-10-20 · Language: en - Canonical page: https://hysenlabs.com/projects/interactiveadvertisingbureau-gdpr-transparency-and-consent-framework ## A specification repository, not a software project The first thing to understand is that nothing here runs. The repository is described as hosting the technical specifications for the IAB Europe Transparency and Consent Framework, and the top level listing makes that obvious: the entries are Markdown documents with names such as CMP JS API v1.1 Final.md, Consent string and vendor list formats v1.1 Final.md, Mobile In-App Consent APIs v1.0 Final.md, URL-based Consent Passing_ Framework Guidance.md and v1.1 Implementation Guidelines.md, plus two directories, Consent String SDK/ and TCFv2/. There is no package manifest, no build script and no test suite in that listing. The project's own description says the specifications help the digital advertising industry interpret and comply with EU rules on data protection and privacy, notably the GDPR, and the framing question is what it is for: ensuring that all parties in the digital advertising chain comply with the GDPR and the ePrivacy Directive when processing personal data, or when accessing or storing information on a user's device such as cookies, advertising identifiers, device identifiers and other tracking technologies. The audience is therefore the engineers and product teams on both sides of the ad request: the consent management platform vendors who build the CMP, the publishers and SSPs who deploy it, and the vendors whose identifiers appear in the consent string. Everyone has to agree on the wire format, and this is where that agreement is written down. ## Two generations of specifications in one tree The tree contains the current framework and the previous one side by side, which is the most confusing thing about navigating the repository and also the most useful. The v1.1 final specifications listed by the README are the Consent Management Provider JavaScript API v1.1 Final, referred to as the CMP JS API v1.1, the consent string and vendor list formats v1.1 Final, and the Mobile In-App CMP API v1.0. These are described as currently adopted in the industry. Then there is version 2. The README states that the v2 specifications were released on 21 August 2019 with industry adoption commencing in the first half of 2020, and that they include the Consent Management Platform API v2.0 and the Transparency and Consent String with Global Vendor List format v2.0. In the file listing, version 2 lives in the TCFv2/ directory. So a reader looking for the current specification has to know which generation their counterpart is implementing, and a reader looking for the older one finds both a set of flat documents and a directory. The naming is also inconsistent, with a stray space and underscore in URL-based Consent Passing_ Framework Guidance.md, and a file called pubvendors.json v1.0 Draft for Public Comment.md, which is a draft from a public comment round rather than a final artefact. That mix of final, draft and superseded material in a single repository is a real hazard for anyone treating a file as normative. ## The consent string and the JavaScript API are the load bearing parts Two of the documents do most of the engineering work. The CMP JavaScript API is the interface a publisher page calls to obtain consent. The vendor builds a CMP that implements this API, and the page asks it for signals, which the CMP then encodes into a consent string and passes to the ad stack. The consent string and vendor list formats document specifies how that string is encoded and how the list of vendors it references is formatted, which is what makes a string issued by one CMP interpretable by an ad server or a DSP. The relationship between the two is worth spelling out, because it explains the architecture. The JavaScript API is the interactive part, a call and response in the browser. The consent string is the durable part, an opaque value that travels with the ad request and encodes what was consented to and by whom. The vendor list is the shared vocabulary those encoded identifiers refer to. That design has a consequence for implementers. The string format is a wire contract between parties who do not share code, so the specification document is the only shared reference. The Consent String SDK/ directory in the tree is the part closest to executable code, and the v1.1 Implementation Guidelines document covers how the pieces fit together in practice. Mobile is handled separately by the Mobile In-App Consent APIs v1.0 Final document, since an app has no browser page and no cookie jar to work with. ## URL-based consent passing and the gap around it One entry in the tree is a guidance document rather than a specification: URL-based Consent Passing_ Framework Guidance.md. It exists because a consent string has to travel somewhere, and in a server-to-server ad request there is no browser context to carry it. The file's status matters more than its name suggests. It is framed as framework guidance rather than as one of the numbered final specifications, which suggests it describes how the specifications should be interpreted in a particular flow rather than defining a new contract. Nothing else in the tree describes it, and the README does not list it among the adopted v1.1 or v2 specifications. For an engineer, this is the kind of document that determines whether an ad request carries a valid string or an empty one, and it is the document most likely to be outdated relative to the others, since the final specifications are versioned and dated while a guidance document does not show that in its filename. The other loose end is the vendor list. The README says the Global Vendor List and the CMP List are resources found at iabeurope.eu/tcf, not files in this repository. That is correct in principle, since the lists change far more often than the specifications, but it means a runtime dependency on an external service that no version in this tree pins. ## Who writes the specifications and who governs them The governance model is documented, and for a standards body it is the part that determines whether the documents can be relied on. Contributions come from the IAB Tech Lab GDPR Technical Working Group, whose members provide contributions to the repository. The README states that participants in that working group must be members of IAB Tech Lab, and that technical governance for the project is provided by the IAB Tech Lab GDPR Commit Group. So the document set is produced by a closed group of member companies and steered by a separate commit group. IAB Tech Lab itself is described as a non-profit consortium with a global member community of digital publishers, ad technology firms, agencies and marketers, founded in 2014, headquartered in New York City with staff in San Francisco, Seattle and London. Its other work is listed, including the OpenRTB real-time bidding protocol, the ads.txt anti-fraud specification, the Open Measurement SDK for viewability and verification, the VAST video specification and the DigiTrust identity service. IAB Europe is the European-level industry association behind the framework, and the two bodies have distinct roles: Tech Lab stewards the technical specifications, IAB Europe runs the framework and hosts the resources. The practical consequence for an implementer is that specification changes arrive through a member process rather than a public pull request, and that the version numbers you see in the file names are the negotiation output. ## The disclaimer puts compliance on the reader The README carries a full legal disclaimer, and it is unusually explicit about the limits of what these documents give you. The standards, specifications and measurement guidelines are provided as is and as available. Tech Lab disclaims all express, implied and statutory warranties, including warranties of merchantability, fitness for a particular purpose and availability, and where applicable law would not permit such a disclaimer, the scope and duration of the warranty is the minimum permitted. Then the sentence that matters most for an engineering decision: the products and services do not constitute business or legal advice, and Tech Lab does not warrant that using them will cause you or your products to be in compliance with any applicable laws, regulations or self-regulatory frameworks. You are solely responsible for compliance, including with data protection laws such as the Personal Information Protection and Electronic Documents Act in Canada, the Data Protection Directive in the EU, the E-Privacy Directive in the EU, the General Data Protection Regulation in the EU, and the E-Privacy Regulation as and when it becomes effective. That list is a good summary of the scope. The framework is a technical interoperability contract, and interoperability is not the same thing as lawful processing. A CMP that faithfully implements the API can still be unlawful, and the framework's own authors say so in writing. ## Creative Commons terms and a repository with no releases The licence, according to the README, is the Creative Commons Attribution 3.0 Licence for the IAB Europe Transparency and Consent Framework technical specifications governed by IAB Tech Lab, with a link to the licence text and the Creative Commons postal address. CC BY 3.0 is the right choice for a specification, and it is worth being explicit about what it permits: you may copy, distribute and adapt the documents, including commercially, provided you give appropriate credit, link to the licence, and indicate whether changes were made. For an engineer this means a specification can be quoted in internal design documents and in vendor contracts, and a derived internal encoding guide can be shared, all with attribution. One discrepancy is worth noting for anyone checking licences automatically. The repository's own licence field records the value as unknown, while the README states the Creative Commons Attribution 3.0 terms and the file listing shows no LICENSE file at the top level. A scanner that reads only repository metadata will therefore report nothing useful, and a scanner that only looks for a LICENSE file will report nothing either. On maintenance, the repository is not archived and the last push was on 2026-08-07, and it publishes no GitHub releases, which is normal for a document set where versions live in file names rather than in tags. There is no changelog in the tree, so tracking what changed between revisions means diffing the documents themselves. ## Conclusion Read this repository if you implement anything in the ad technology chain, because it is the authoritative text for the CMP JavaScript API, the consent string encoding and the vendor list formats, and it is licensed CC BY 3.0 so it can be quoted and redistributed with attribution. Do not treat it as a compliance tool or a library, since it contains specifications and a Consent String SDK directory rather than a supported implementation, and the disclaimer puts compliance responsibility on the user. Before you build against it, verify two things: which generation you are targeting, with v1.1 documents and the TCFv2 directory both present in the tree, and where the vendor list and CMP list come from at runtime, since the README places those resources at iabeurope.eu/tcf rather than in this repository. ## FAQ ### What is inside the IAB GDPR Transparency and Consent Framework repository? It holds specification documents rather than a runnable library: CMP JS API v1.1 Final, Consent string and vendor list formats v1.1 Final, Mobile In-App Consent APIs v1.0 Final, URL-based Consent Passing Framework Guidance, v1.1 Implementation Guidelines, a Consent String SDK directory and a TCFv2 directory. ### Which version of the Transparency and Consent Framework should an implementer target? The README lists the v1.1 final specifications as currently adopted and states that the v2 specifications were released on 21 August 2019 with adoption beginning in the first half of 2020, covering the Consent Management Platform API v2.0 and the Transparency and Consent String with Global Vendor List format v2.0. ### Where do I find the Global Vendor List and the CMP List? The README directs you to iabeurope.eu/tcf for resources including the policy FAQ, the Global Vendor List and the CMP List. Neither list is stored in this repository, so a runtime implementation depends on an external service that no document in the tree pins to a version. ### Do these specifications make my implementation GDPR compliant? No. The README disclaimer states that the products and services do not constitute business or legal advice and that Tech Lab does not warrant compliance, leaving the user solely responsible for compliance with laws such as the GDPR, the E-Privacy Directive and the Data Protection Directive. ### What licence applies to the IAB TCF specifications? The README states that the specifications are licensed under the Creative Commons Attribution 3.0 Licence, which allows copying, distribution and adaptation with attribution. The repository's own licence field records the value as unknown, so automated licence checks will not find it there. ## Sources - [InteractiveAdvertisingBureau/GDPR-Transparency-and-Consent-Framework on GitHub](https://github.com/InteractiveAdvertisingBureau/GDPR-Transparency-and-Consent-Framework) - [Issues](https://github.com/InteractiveAdvertisingBureau/GDPR-Transparency-and-Consent-Framework/issues) - [README](https://github.com/InteractiveAdvertisingBureau/GDPR-Transparency-and-Consent-Framework/blob/master/README.md) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/interactiveadvertisingbureau-gdpr-transparency-and-consent-framework