Fall 2025 Public Comment Period Now Open for Global Privacy Protocol and Data Deletion Request Framework Updates

IAB Tech Lab has opened a new public comment period covering proposed updates to two key technical specifications: the Global Privacy Protocol (GPP) and the Data Deletion Request Framework (DDRF).

These updates continue Tech Lab’s commitment to providing scalable, interoperable solutions that support privacy, transparency, and accountability across the digital advertising ecosystem.

The proposed changes to the GPP introduce new U.S. state privacy sections and a re-architected string structure designed to improve long-term flexibility. Updates to the Data Deletion Request Framework enhance clarity around token formats, strengthen key management and security guidance, and expand implementation options for extensibility.

Feedback on both specifications may be submitted to support@iabtechlab.com or via GitHub during the public comment period, open until December 1st, 2025.

Global Privacy Protocol Updates

IAB Tech Lab has released for public comment updates to the Global Privacy Protocol (GPP) technical specifications. This update expands the framework’s coverage to reflect newly enacted U.S. state privacy laws and introduces proposed structural improvements designed to enhance scalability and interoperability across future releases.

Expanding Coverage for Four New U.S. States

The latest update adds four new U.S. state sections, Maryland, Indiana, Kentucky, and Rhode Island, all of which have recently enacted comprehensive privacy laws that go into effect in 2025 and 2026. These four new states introduce a re-architected string structure designed to future-proof them. Key proposed changes include:

Introduction of Section Headers

Mirroring the general GPP string structure, the proposal introduces a section header to define the order and inclusion of subsections within each state string. This header acts as a table of contents, providing clear visibility into which subsections are present and preventing ambiguity when optional subsections are introduced.

Moving Select Fields to Subsections

To minimize disruptions as privacy requirements evolve, fields that are more likely to change will be moved from the Core subsection into dedicated subsections. The GPP already includes the concept of subsections, such as the GPC subsection included in other U.S. state sections. In this update, the Sensitive Personal Information Consent (SPI) fields previously included in the Core subsection are now isolated in their own subsection. This modular approach allows implementers to continue parsing essential fields, such as sale, share, and targeted advertising opt outs, even when section versions are incremented to accommodate updates in higher-risk areas like SPI Consents.

Below is an example illustrating how section headers and subsections would appear within a GPP string.

Increased Transparency for Downstream Vendors on Which Section(s) Apply

It’s important that downstream vendors can easily identify which GPP sections a CMP both supports and has determined to apply for a given user. Currently, there’s no standardized server-side way for vendors to know whether a CMP supports a section, doesn’t support it, or hasn’t made any jurisdictional assessment.

This ambiguity can affect how vendors interpret signals and without this clarity, systems may over- or under-apply privacy rules. To close this gap, Tech Lab is proposing a new mechanism to communicate supported sections alongside applicable sections, extending the existing client-side CMP API (PingReturn.supportedAPIs) to downstream and server-side use cases.

There are two potential options, Option A and Option B, each with different approaches to communicating this information, and Tech Lab invites industry feedback on both to determine the most effective path forward.

Option A: Encode Supported Sections in the GPP Header

This approach embeds the list of supported sections directly within the GPP string header, alongside the existing fields that define which sections are included and which apply to the user.

Under this option, the header would include:

SupportedSections – The list of section IDs the CMP supports, as directed by the first party.
SectionApplies – The section(s) determined to apply for the given transaction.

This method mirrors how the TCF currently communicates gdprApplies, creating parity between frameworks.

The benefits of this approach include:

Simple, compact, and fully encoded within the GPP string.
Easier for vendors to parse using existing infrastructure.
Provides consistent signaling for both supported and applicable sections.

Some drawbacks of this approach include:

The GPP string must be updated whenever a CMP adds or removes supported sections as directed by publishers.
The new signal may not be considered essential from a data minimization standpoint, though it does not significantly change the entropy of the GPP string.
In the future, if signed strings are introduced as a feature, this would be additional overhead if the string is updated frequently.

Option B: New URL Parameters, Macros, and OpenRTB Fields

This alternative proposes introducing a new “supported sections” signal outside of the GPP string via additional URL parameters, macros, and OpenRTB fields.

New fields would include:

URL parameter: &gpp_ssns
Macro: ${GPP_SSNS}
OpenRTB field: regs.gpp_ssns
App key: IABGPP_GppSsns

These additions would complement existing parameters such as &gpp (the full string) and &gpp_sid (the applicable section IDs), enabling downstream systems to understand which sections the CMP supports even if they do not appear in the GPP string itself.

The benefits of this approach include:

Reduces the size and frequency of GPP string updates.
Easier adoption for systems that already parse URL parameters or OpenRTB objects.

Some drawbacks of this approach include:

Requires coordinated updates across multiple implementation layers that may have longer adoption cycles such as macros in creatives.
Potential risk that the signal could be omitted unintentionally, which could lead to ambiguity.

Data Deletion Request Framework Updates

In parallel, Tech Lab has released proposed updates to the Data Deletion Request Framework (DDRF) specification. These proposed changes provide greater clarity around token formats, strengthen key rotation and framework security practices, and improve extensibility for implementers. The updates are designed to enhance interoperability, security, and long-term maintainability across the data deletion request ecosystem.

Updates to Address Ambiguity in rqJWT.sub & idJWT.sub Claim Format

The update refines the structure and usage of two key JWTs used within the framework:

Renaming idJWT to orJWT (Originating Requester JWT): To address privacy considerations and improve clarity, the former idJWT has been renamed to orJWT, reflecting its purpose as a token generated by the originating requester. The idJWT.sub (subject) claim has been removed.
Updated rqJWT.sub Format: Instead of embedding a JSON object within the sub claim, three new dedicated claims (identifierValue, identifierType, and identifierFormat) have been introduced. This change avoids the need to stringify a JSON object within the sub claim.

These adjustments provide clearer alignment with JWT best practices while reducing parsing complexity and promoting data minimization.

Key Rotation Guidance & Improved Framework Security

Several significant updates improve the framework’s cryptographic hygiene and rotation practices:

Replacing publicKey with jwksUri: The publicKey field in dsrdelete.json has been replaced with a required jwksUri field. This aligns the framework with established OAuth and OpenID Connect conventions, where a JWKS endpoint hosts the relevant key set.
Requiring alg and kid Parameters: The alg (algorithm) and kid (key ID) parameters are now required for each JWK, ensuring stronger validation and eliminating algorithm ambiguity risks.
Introducing pollFrequency: A new required pollFrequency field is included in both dsrdelete.json and the hosted jwks.json file, expressed in seconds, to standardize how frequently participants should refresh cached keys and metadata.
Key Rotation Guidance: The specification now recommends maintaining a cache of partner keys and refreshing whenever a key ID (kid) mismatch occurs. Example JSON files have been updated to demonstrate multi-key sets supporting phased key rotations.

Refined Result Codes

The result code system has been expanded to provide clearer feedback on request outcomes and error handling:

acJWT tokens are now reserved for communicating the substantive result of a deletion request.
Separate result codes and strings are now defined for the rqJWT and orJWT, improving troubleshooting granularity.
New result codes cover scenarios such as invalid tokens, malformed structures, timestamp errors, and unsupported identifier types or formats.

This separation enhances diagnostic clarity and ensures consistent handling of deletion request responses across implementations.

Extensibility and Discoverability Improvements

To support greater flexibility and scalability, several optional parameters have been added:

optionalParameters: Allows implementers to add custom, non-standard fields to dsrdelete.json, enhancing extensibility.
dsrdeleteJsonUri: Enables organizations with multiple domains to designate a single domain as the canonical host for the full configuration file.
publishedJwksUri: Encourages public hosting of JWKS endpoints to facilitate secure key rotation practices.