In June 2024 IAB Tech Lab published the first version of the Data Deletion Request Framework (DDRF), which builds upon IAB Tech Lab’s portfolio of core privacy compliance initiatives, including the Global Privacy Platform, the Accountability Platform, and the Privacy Taxonomy project. Collectively, these initiatives form a foundational framework for streamlining privacy regulatory compliance, handling consumer data privacy concerns within the digital advertising supply chain and advancing responsible data-handling practices in digital advertising.
Recently updates to the Data Deletion Request Framework have been released for public comment (due by 1st December 2025) designed to bring the framework up-to-date with the ever-evolving legislations globally and improve long-term flexibility.
We wanted to provide some awareness and guidance on the DDRF as here in Australia the Privacy Review is now in full swing. We will firstly provide some general background and context on this topic and review what currently exists in other markets. Then we’ll look at what the Data Deletion Framework is and it works in practice for sellers, buyers and vendors within the digital advertising ecosystem.
Some background on consumer requests for data deletion
For now, Australia does not have a general right to delete or erase personal data on demand. The data protection landscape is mainly governed by the Privacy Act 1988, which establishes a national framework for handling personal information by government agencies and private sector organisations meeting certain criteria (such as those with an annual turnover of AUD 3m or more).
The Privacy Act incorporates 13 Australian Privacy Principles (APPs) that outline obligations for entities in collecting, using, disclosing, and securing personal data. These are listed below:
Within these are APP 11, which requires organisations to take reasonable steps to destroy or de-identify personal information when it is no longer needed for any permitted purpose. Businesses must act proactively to delete data they no longer need, rather than waiting for consumer requests and the obligation is on the organisation to determine when data is no longer needed, not on consumers to request deletion.
Under APP 12, individuals can request access to their personal information held by an entity, which must be provided in a reasonable manner and time-frame (typically within 30 days) unless exceptions apply, such as threats to safety or commercial sensitivity. Also, APP 13 mandates that entities take reasonable steps to correct inaccurate, incomplete, or misleading information upon request or proactively, and notify relevant third parties of changes.
The EU’s GDPR Article 17 came into force in May 2018 (also known as the ‘right to be forgotten’) allows individuals to request erasure when data is no longer necessary, consent is withdrawn, data was unlawfully processed, or specific legal grounds are met.
image source: usercentrics.com
In the US, California (CCPA/CPRA) and Virginia (VCDPA) both provide comprehensive deletion rights and other U.S. states are progressively adopting similar provisions. Across Asia-Pacific – Japan (APPI, since 2017), South Korea (PIPA, since 2011), and China (PIPL, since November 2021) all provide explicit right to data deletion provisions.
Hence a holistic and flexible solution for handling data deletion requests for the advertising industry across the digital advertising supply chain globally was required, resulting in a dedicated framework to help companies comply with global privacy laws, without mandating specific execution methods.
What is the Data Deletion Request Framework?
Traditionally the adtech ecosystem had relied upon manual, ad hoc processes to handle data deletion requests, primarily through email. This created significant operational challenges, including delays, inconsistencies, and compliance risks. The Data Deletion Request Framework (DDRF) was designed to address this gap by replacing fragmented manual processes with a consistent, crypto-graphically secured technical protocol. It focuses on communication rather than deletion execution, enabling requests to propagate securely through interconnected advertising technologies.
The DDRF standardises the transmission of deletion requests across the digital advertising ecosystem and enables companies to efficiently communicate consumer-initiated data erasure requests across internal systems and external supply chain partners – thereby reducing manual effort and enhancing operational accountability. It is designed as a non-proprietary, interoperable standard, ensuring that smaller vendors and publishers can implement it without vendor lock-in. The specification is maintained in a public GitHub repository in which all updates can easily be reviewed.
Recent updates to the Data Deletion Request Framework have been released for public comment (due by 1st December 2025) designed to enhance the clarity around token formats, strengthen key management and security guidance, and expand implementation options for extensibility.
The DDRF is part of IAB Tech Lab’s broader privacy compliance portfolio, which also includes the Global Privacy Platform (GPP), the Accountability Platform, and the Privacy Taxonomy.
How Does it Work?
The foundation of the DDRF is a dsrdelete.json configuration file that each participating organisation must publish at the root of their domain (e.g. Google’s can be viewed at static.doubleclick.net/dsrdelete.json ). This file contains the relevant configuration parameters, including their public cryptographic key (used for their digital signature verification along with the private key) and the API endpoint, where the data deletion requests and/or their acknowledgement should be sent over to:
- API Endpoint: The URL for submitting deletion requests (e.g., https://example.com/api/delete/).
- Supported Identifiers: Types such as “email,” “idfa” (ID for Advertisers), or “gaid” (Google Ad ID), along with formats like “sha256” (hashed) or “raw.”
- Public Keys: For cryptographic verification, formatted according to the JSON Web Key (JWK) standard (RFC 7517), using the Ed25519 curve for EdDSA signatures.
- Vendor Script (optional): JavaScript for handling requests if no endpoint is provided.
The IAB Tech Lab maintains a centralised directory of these files, crawled from participating domains and accessible via an API or tools portal, facilitating bulk lookups and discovery for multi-domain companies.
Deletion requests are initiated by a first-party (e.g., a publisher) on behalf of a consumer, formatted as JSON payloads sent via POST to API endpoints discovered through configuration files. Cryptographic signatures ensure authenticity, and acknowledgments confirm receipt, reducing reliance on ad hoc emails or custom solutions.
It operates as a structured sequence that ensures requests are initiated, propagated, verified, and confirmed without ambiguity by using JSON Web Tokens (JWT) for secure data transmission, ensuring the authenticity of deletion requests. Requesters sign JWTs with private keys, while recipients verify them using public keys hosted on the requester’s domain. It leverages registered public claims from the JWT standard for consistency and introduces custom private claims for deletion requests.
There are three distinct JWTs delineated:
- Identity JWT (idJWT): Generated by the 1st party, containing the ID to be deleted and authentication information.
- Request JWT (rqJWT): Includes the Identity JWT and additional request transaction details, generated for each vendor requiring communication.
- Acknowledgement JWT (acJWT): Generated by a recipient, including the Request JWT and acknowledgment status, confirming the success or failure of the communication.
The complete deletion request workflow operates through:
- Discovery: The first-party publisher discovers all vendors’ and recipients’ dsrdelete.json files containing API endpoints and supported identifiers.
- Request Preparation: Publisher creates an Identity JWT containing the consumer identifier and generates a Request JWT with transaction metadata.
- Cryptographic Signing: The request is digitally signed with the publisher’s private key.
- Transmission: The Request JWT is transmitted via HTTPS to each vendor’s API endpoint defined in their dsrdelete.json
- Validation: Each recipient validates the signature using the publisher’s public key.
- Authentication Verification: Recipient confirms the request originated from a legitimate first-party.
- Processing: Upon successful validation, the recipient processes the deletion request.
- Acknowledgment: The recipient returns an Acknowledgement JWT with a result code indicating success or failure.
- Confirmation Tracking: The first-party aggregates responses from all recipients to confirm complete deletion.
In Conclusion
As of November 2025, the DDRF has gained significant traction, including endorsement from the UK’s Information Commissioner’s Office (ICO) in July 2025, which formally recognises its potential to improve third-party handling of deletion requests in online tracking scenarios.
With the DDRF our industry can look to continue to build trust with consumers, by ensuring that there is an efficient, consistent and reliable process for when a consumer wants to exercise their data deletion rights that this deletion request can be communicated throughout the ecosystem. This ensures that the personal data they want deleted is actually deleted as required by law – which will be a critical requirement here in Australia as Privacy Laws continue to come into force.
Australia’s Privacy Act does not yet mandate a general right to data deletion (as of 6th November 2025) but ongoing reforms may introduce this in future tranches, so reviewing the requirements for DDRF in advance is advisable for compliance readiness and we will ensure local industry is up-to-speed on any potential legislative changes.
Additionally, any Australian companies handling data from regions like the EU (GDPR) or US relevant states (CCPA) should look to implement DDRF to meet any international deletion requests received efficiently and avoid any potential ramifications.
To review the latest DDRF updates recently proposed (November 2025) you can access them via the dedicated GitHub repository – CLICK HERE
