/ 
GDPR-IAB-TCFv2-0.400
⭐ Starred 1 / TODO

NAME

TODO - Roadmap, ecosystem, and help-wanted items for GDPR::IAB::TCFv2

STATUS

GDPR-IAB-TCFv2 entered maintenance mode on 2026-05-09 with the v0.400 release. The core parser, validator, and CMP-validator surfaces are considered feature-complete for IAB TCF v2.3.

In maintenance mode the maintainer commits to:

  • bug fixes,

  • security fixes,

  • CPAN-tester regression triage,

  • tracking IAB-spec updates (TCF v2.4 / v3 if and when they ship).

Larger feature work -- the three remaining roadmap phases below, the distribution items, and the sister-distribution ideas -- is now tracked as help-wanted issues on GitHub. Patches and PRs from the community are still welcome and will continue to be reviewed.

COMPLETED PHASES

The phases below shipped between v0.270 and v0.400. They are listed here for historical context only; details live in CHANGELOG.md and the linked PRs.

is_vendor_consent_allowed, is_vendor_legitimate_interest_allowed, is_vendor_allowed_for_flexible_purpose, plus strict mode.

Phase 1 -- TCF v2.3 segments and parser robustness

Disclosed Vendors / Allowed Vendors segments, multi-segment safety, has_vendor_disclosure, has_publisher_restrictions, the vendor_id filter on TO_JSON, and the automated release workflow.

Phase 2 -- Declarative validator interface

GDPR::IAB::TCFv2::Validator with validate / validate_all and Validator::Result.

Phase 3 -- Alignment and cleanup

Purpose names normalized to TCF v2.3 wording; POD streamlined.

Phase 4 -- Performance pass

Bitfield decode optimizations and golden-corpus benchmarks.

Phase 5 -- CMP validator

GDPR::IAB::TCFv2::CMPValidator with file / JSON / URL loading, staleness warning, and integration into the main validator as a rule.

Phase 6 -- Structured failure reporting

Five sub-phases (6.1 -- 6.5) delivering Validator::Reason codes, Validator::Failure objects, the TCF LI carve-out, distinct publisher-restriction reasons, and per-call list overrides.

HELP WANTED -- ROADMAP PHASES

Three roadmap phases were originally planned for inclusion in this distribution but are now open for community contribution. Each is self-contained and can ship as an independent PR; pick one and open (or claim) the corresponding help-wanted + roadmap issue on GitHub.

Phase 7 -- GVL-Aware Validator

Bridge the IAB Global Vendor List schema to the Phase 2 validator so callers do not have to translate vendor entries by hand.

Scope:

  • from_gvl_vendor_entry($vendor_entry) -- accept a single GVL vendor entry ({ id, purposes, legIntPurposes, flexiblePurposes }) and return the keyword-argument list expected by Validator->new.

  • from_gvl($gvl_doc, $vendor_id) -- look up the vendor in a parsed GVL document and return a fully configured Validator; fail fast if the vendor ID is missing.

  • Flexible GVL input: file path, raw JSON string, or pre-parsed hashref.

  • CLI integration: iabtcfv2 validate --gvl path/to/gvl.json -v 32 ... should derive -C / -L / -F from the GVL entry.

  • Tests: golden GVL fixture covering vendors with and without flexible purposes; round-trip from_gvl_vendor_entry against a hand-crafted entry.

Phase 8 -- Features, Special Features, Special Purposes

Extend the validator beyond standard purposes to cover the rest of the TCF taxonomy. Should consume the REASON_* codes introduced in Phase 6.

Scope:

  • Validator support for Special Features (opt-in, e.g. precise geolocation): require the bit in the TC string when listed.

  • Validator support for Features (vendor-declared): no consent required, but cross-check the vendor's GVL declaration once Phase 7 lands.

  • Validator support for Special Purposes: legitimate-interest-only by spec; check vendor declaration without requiring a consent bit.

  • Surface on the CLI as --special-features / --features / --special-purposes (comma-separated, same shape as -C / -L).

  • Tests: extend t/06-validator.t with subtests per category; extend t/10-cli-iabtcfv2.t with CLI subtests.

Phase 9 -- CLI Configuration Loading

Reduce CLI boilerplate by letting common flags come from the environment or a config file.

Scope:

  • Map a curated set of env vars to CLI flags: IABTCFV2_VENDOR_ID, IABTCFV2_CONSENT_PURPOSES, IABTCFV2_LEGITIMATE_INTEREST_PURPOSES, IABTCFV2_FLEXIBLE_PURPOSES, IABTCFV2_MIN_POLICY_VERSION. Explicit CLI flags always win.

  • Optional config-file discovery: .iabtcfv2rc in $PWD or $HOME (plus .env-style loading if present). Documented precedence: CLI > env > file > built-in defaults.

  • iabtcfv2 config (or validate --print-config) to dump the resolved configuration as JSON for debugging.

  • **Tests:** a CLI subtest that sets the env vars, runs validate without the matching flags, and asserts the same outcome as the explicit invocation.

Phase 10 -- Advanced Error Handling

Modernize exception handling across the library.

Scope:

  • Implement GDPR::IAB::TCFv2::Error exception objects.

  • Overload stringification to provide clean messages while retaining metadata (code, file, line).

  • Refactor croak / die calls in the library to throw objects.

  • Update CLI to catch objects and simplify its sanitization logic.

Phase 6 follow-up -- CMPValidator structured failures (non-blocking)

Round out Phase 6 by migrating GDPR::IAB::TCFv2::CMPValidator (Phase 5) onto the structured failure-reporting model the rest of the validator already uses. Today CMP-level failures are stringly-typed croaks; this item brings them onto Validator::Failure with stable machine-readable codes.

Scope:

  • Add a REASON_CMP_* family to Validator::Reason: REASON_INVALID_CMP (CMP ID not in registry), REASON_CMP_DELETED (retired CMP, deletedDate honored), REASON_CMP_UNKNOWN (registry loaded but ID unclassifiable). Update reason_string() to cover them.

  • Refactor CMPValidator (or its consumer wrapper inside the main Validator rule) to emit Validator::Failure objects with the matching codes instead of plain croaks.

  • Backwards compat: the human-readable text emitted by Validator::Result stringification must stay the same so existing CLI output is unchanged.

  • Tests: extend t/14-cmp-validator.t (and/or t/16-validator-failures.t) with subtests asserting each new code, reusing the fixed reference dates already in place for determinism.

HELP WANTED -- DISTRIBUTION

These items are about packaging the existing code, not about adding features.

Linux package artifacts (.deb and .rpm)

Wire up a GitHub Actions workflow that, on every v* tag, builds a .deb and a .rpm from the released tarball and uploads both as assets on the corresponding GitHub Release. Both packages are pure Perl (noarch / all), so a single Linux runner per format is enough; no build matrix, no cross-arch concerns.

Suggested toolchain:

  • .deb: dh-make-perl --build --cpan-mirror=file:./ against the make dist tarball. Produces libgdpr-iab-tcfv2-perl_VERSION_all.deb. Confirm the resulting debian/control picks up bin/iabtcfv2 as an executable and respects the META recommends.

  • .rpm: cpanspec on the tarball to produce a .spec, then rpmbuild -ba inside a fedora:latest container. Produces perl-GDPR-IAB-TCFv2-VERSION-1.noarch.rpm.

  • Upload both via gh release upload "$GITHUB_REF_NAME" *.deb *.rpm.

Out of scope (separate, larger efforts -- not part of this item): filing an ITP bug to ship the package via Debian proper, hosting a signed apt repo, or maintaining a Fedora COPR. The deliverable here is artifacts on the Release page, downloadable with wget + dpkg -i or dnf install ./perl-GDPR-IAB-TCFv2-VERSION-1.noarch.rpm.

Homebrew tap (macOS + Linux)

Stand up a self-hosted Homebrew tap repository (peczenyj/homebrew-tap) with a Formula/iabtcfv2.rb formula that installs the CLI from the released CPAN tarball. Users opt in with:

brew tap peczenyj/tap
brew install iabtcfv2

Maintenance contract: a small CI step on this repository's release event that opens a PR against the tap repo bumping the formula's url + sha256. Self-hosted (not homebrew-core), so no external review queue and no homebrew-core's "notable + stable + popular" gate.

Same formula works on Homebrew on Linux (Linuxbrew), so this single channel covers macOS plus a slice of Linux developer machines for free.

Snap package (Ubuntu / cross-distro Linux)

Author a snapcraft.yaml that packages bin/iabtcfv2 and the Perl runtime, and publish to snapcraft.io on every v* tag. Users install with:

sudo snap install iabtcfv2

Heads-up for the contributor: snaps run under confinement, so any file paths the CLI reads (config files, GVL JSON dumps) need to be inside the snap-allowed locations or a personal-files / system-files plug must be declared and connected. Path the release notes accordingly so first-time users do not hit a silent "file not found" inside the sandbox.

AUR package (Arch Linux)

Publish a PKGBUILD for Arch's user repository. The recipe is short -- makepkg drives a perl Makefile.PL && make && make install against the release tarball. Best handled by a community co-maintainer rather than this repo's CI; volunteer contributions welcome.

ECOSYSTEM -- SISTER DISTRIBUTIONS

The following ideas are intentionally separate CPAN distributions rather than features of this one. Each adds a runtime dependency on its host framework, so packaging them separately keeps GDPR::IAB::TCFv2's own deps lean.

Highest priority

  • GDPR::IAB::TCFv2::Validator::LIVR

    LIVR rule-engine binding for JSON-shaped TC payloads.

  • GDPR::IAB::TCFv2::Validator::TypeTiny

    Reusable Type::Tiny constraints (parameterized by purpose / vendor sets) for Moo, Moose, or pure-Perl callers that prefer type-level enforcement.

  • Plack::Middleware::GDPR::TCFv2

    Plack middleware that decodes a TC string from a request header or cookie, attaches the parsed GDPR::IAB::TCFv2 object to $env, and short-circuits the response when consent is missing or invalid.

Nice to have

  • GDPR::IAB::TCFv2::Validator::Moose

    Moose attribute traits and role-based validation for projects that already use Moose end-to-end.

  • GDPR::IAB::TCFv2::Validator::FormValidator

    Data::FormValidator profile glue for legacy applications that drive business validation through DFV.

  • GDPR::IAB::TCFv1

    A standalone parser for the legacy IAB TCF v1 / v1.1 consent string format (April 2018 -- August 2020, superseded by TCF v2.0). The wire format is unrelated to v2 -- different bit layout, no segment structure, smaller fixed core -- so it does not belong inside this distribution.

    Audience is intentionally narrow: log spelunkers, audit teams, and the historically curious. A useful contribution would expose a similar surface to GDPR::IAB::TCFv2 (Parse, TO_JSON, simple purpose / vendor predicates) without dragging in v2's validator machinery.

HOW TO CLAIM AN ITEM

  1. Open a GitHub issue (or comment on the existing one) referencing the phase or sister-distribution name above. Include a rough scoping sketch: what API you are proposing, what tests you will add, and which existing module the work will touch.

  2. Wait for a maintainer to assign the issue. This avoids duplicate effort and surfaces any spec questions early.

  3. Follow the patching workflow in CONTRIBUTING.pod: branch from devel, run the full test suite (prove -lr t plus AUTHOR_TESTING=1 prove -lr xt), open a PR.

OUT OF SCOPE

The following are intentionally not on the roadmap:

  • TCF v1 / v1.1 support inside this distribution. The two wire formats share nothing but the IAB acronym, so v1 belongs in a sibling distribution rather than as a code path here. See the GDPR::IAB::TCFv1 entry under "ECOSYSTEM -- SISTER DISTRIBUTIONS" if you are interested in claiming it.

  • Network-side discovery of CMP or GVL endpoints. The library accepts pre-loaded data; fetching is the caller's responsibility (or the optional HTTP::Tiny path inside CMPValidator).

  • Persistent caching of parsed strings. TC strings are cheap to parse; caching is a deployment concern, not a library concern.

SEE ALSO

GDPR::IAB::TCFv2, GDPR::IAB::TCFv2::Validator, GDPR::IAB::TCFv2::CMPValidator, CONTRIBUTING.pod, CHANGELOG.md.