The ‘Right to Delete’ is a Data Subject Right (DSR) included as part of the GDPR, US state privacy laws, and additional privacy legislation such as Quebec Law 25.
The US Privacy specification , which was deprecated on 31 January 2024, supported California Consumer Privacy Act (CCPA) requirements with an included data deletion request handling mechanism. However, the original mechanism only supported the CCPA, which is now too limited a scope. As privacy legislation evolves across California, other US state laws, and global jurisdictions beyond GDPR, the data deletion request framework needs to also evolve.
Handling data deletion request signals is a challenge for the adtech ecosystem. Existing DSR tools in-market do not have integrations with adtech companies. To support adtech, we need a protocol that successfully communicates data deletion requests to participants, ensuring all related parties who share data can receive the request signal. This specification describes a data deletion signaling mechanism that is intended to be an interoperable standard within the Global Privacy Platform (GPP).
The following terms have specific meaning within this document:
- Deletion Request
- A deletion request is a request made by a user to a party, referred to as a 1st-party, which they have a direct relationship with.
- Deletion Request Transaction
- A deletion request transaction is an interaction consisting of the communication of a deletion request by a requester and the acknowledgement of the request by a recipient.
- Deletion Request Chain
- A deletion request chain is a series of one more deletion request transactions originating from a given requester.
- 1st Party
- A 1st Party (also first-party) is an adtech ecosystem participant which has direct relationships with users and which may receive requests from those users to delete their data.
- Vendor
- A Vendor is an adtech ecosystem participant which has direct or indirect relationships with 1st Parties and which may receive deletion requests from those 1st Parties.
- Requester
- A requester is a party which initiates a data-deletion transaction by communicating a data deletion request on behalf of a user. A 1st-party is always the first requester in a deletion request chain.
- Recipient
- A recipient is a party which receives a deletion request from a requester. Recipients may themselves become requesters in succeeding transactions.
- Provide a standard protocol that allows parties to communicate data deletion request signals.
- Provide a standard for recipients to indicate what must be provided and how it must be packaged to execute data deletion requests.
- Provide a standard for recipients of data deletion requests to validate the 1st-party origin of a request.
- Provide a standard means by which recipients of data deletion requests can determine the authenticity of the requester.
- Provide a standard for recipients to confirm receipt of a data deletion request.
- Provide a standard for parties to have deletion requests and request receipts cryptographically signed by those making and receiving the requests, respectively.
This proposal is focused specifically on defining a two stage process by which deletions are requested and affirmed. In the first stage, requests are communicated from a requester to a recipient and the recipient acknowledges receipt of the request. A recipient may also become a requester if they need to forward the request to partners.
- Verifying the original data-subject request: it is assumed that first-parties will be responsible for authenticating and validating requests prior to communicating them via this protocol.
- How deletion request recipients act on them: it is assumed each participant will decide independently what their obligations for acting on a request and what their requirements are for satisfying those obligations.
- Supporting any other types of data subject rights requests.
- Determining what partners a participant must communicate deletion requests to: it is assumed participants will be responsible for deciding which of their partners they must forward deletion requests to in order to properly honor them.
All participants will be required to publish a file with configuration parameters needed by other participants who support the standard. The file must be called dsrdelete.json and available at a standard location that it is easily discoverable by other participants.
The following information is required from participants in their dsrdelete.json resource:
- All participants must publish cryptographic public keys conforming to the JSON Web Key (JWK) standard ( https://datatracker.ietf.org/doc/html/rfc7517 ), which will be used by other participants to verify JWT signatures generated with the associated private keys.
- All participants must publish in their dsrdelete.json files information 1st Parties will use to determine how to submit deletion requests to them and what the requirements for submitting the requests are (e.g. what identifiers/data must be provided and what API endpoint deletion requests must be sent to).
- All participants must publish an API endpoint as defined in their dsrdelete.json to which requesters can send deletion requests.
This specification employs the JSON Web Tokens (JWT) standard, which supports verifiable transmission of data through the use of cryptographic signatures, to assure deletion requests are valid and authentic. Requesters sign JWTs using their private keys to ensure provenance and authenticity, while recipients verify them using public keys hosted on the requester's domain.
Additionally, this specification leverages some of the registered public claims defined in the JWT standard to take advantage of the existing, generally accepted data value definitions and provide consistency across implementations. It also introduces custom private claims designed specifically for the deletion request use case.
The specification delineates three distinct JWTs: an identity JWT (idJWT), a request JWT (rqJWT), and an acknowledgment JWT (acJWT). Each serves a unique purpose as described below:
- Identity JWT (idJWT): Generated by the 1st party, this idJWT includes the 1st party version of the ID to be deleted along with additional information used to authenticate the origin of the deletion request. The intent is to provide verifiable communication from the originating party that can be provided with tamper protection to all other participants.
- Request JWT (rqJWT): The rqJWT includes the idJWT as a claim, along with additional information for a discrete deletion request transaction between a requester and recipient. For each vendor requiring communication of a deletion request, the 1st party generates a distinct rqJWT. If a vendor needs to communicate the request to vendors they work with, they generate an additional rqJWT for each which includes a copy of the idJWT they received.
- Acknowledgement JWT (acJWT): Generated by a recipient and returned to a requester. The acJWT includes the rqJWT alongside acknowledgement information, including success or an error status.
This model ensures that all recipients can employ the shared idJWT from the request initiator to authenticate its validity. In addition, all recipients will be able to verify the rqJWTs they receive originated with the claimed requester and the acJWT provides requesters and recipients with common proof of a transaction and the success or failure of the communication.
For detailed information on JWT implementation, please refer to: IETF RFC 7519 - JSON Web Tokens (JWT) .
Deletion request sequences always begin with a user requesting that a 1st Party delete their data through a flow provided by the 1st Party as identified in step 1 below. Once the 1st Party has determined that the request needs to be communicated to partners, which partners it must be communicated to, and what information they must be provided with – a series of one or more discrete transactions occurs to propagate the request for each individual identifier subject to the request to all concerned parties.
The two parties in these transactions are a requester, who has received a deletion request from a data subject, and a recipient, who the requester has a data relationship with. The interactions between the requester and recipient are described in steps 2 through 10 below. If a recipient has additional partners with whom they have shared the data to be deleted, they will in turn become the requester in subsequent transactions with their partners.
A given deletion request may be forwarded by a requester to one or more than one recipient and the recipient may in turn forward the request to one or more subsequent recipients. The result will be chains of one or more transactions which fan out across the partner graph.
- *Data Subject requests a data deletion from a 1st Party*
- 1st Party validates the request.
- 1st Party determines what identifiers are subject to the request.
- 1st Party determines partners that data has been shared with which the request must be communicated to.
- 1st party accesses the dsrdelete.json resource of each identified partner to determine how IDs must be formatted for them.
- 1st party generates an initial idJWT for each identifier that is subject to the request.
- Requester generates a deletion packet formatted as an rqJWT which includes the idJWT created in step 1.e., as well as the other values described under Request Data below.
- Requester sends the rqJWT to the Recipient.
- Recipient receives the rqJWT and verifies the signatures of the idJWT and rqJWT using public keys published on the 1st party and requester’s respective domains.
- Recipient acknowledges receipt to the requester with an acJWT. The acJWT includes the original rqJWT and additional acknowledgement values described under Recipient Acknowledgement, including a result code indicating successful receipt of the request or an error.
- Requester verifies the signatures of the acJWT and the embedded rqJWT returned by the Recipient using a public key published on the Recipient’s domain and their own public key.
- *Requester logs the Recipient Acknowledgement acJWT.*
- *Recipient logs the request rqJWT.*
- *Recipient forwards the request as necessary by:
- Determining what partners the request must be forwarded to.
- Accessing the dsrdelete.json resource for each partner to determine how IDs must be formatted for them.
- Generating rqJWTs to be sent to partners using the original identifier idJWT they received and by following steps 2 through 8 above.
- *Recipient, in a separate flow, executes the data deletion.*
The following steps have been marked with an asterisk because they are not part of the standard:
- Step 1 and Steps 7-10.
When a deletion request needs to be propagated to downstream recipients, idJWTs are included in the rqJWT to ensure integrity and authenticity of the original request. Each downstream recipient receives the idJWT and verifies its signature before processing the request based on the information within the rqJWT.
To maintain security and transparency throughout the propagation process, it's essential to follow these steps:
- Inclusion of Original idJWT: The original idJWT, generated by the initial requester (1st Party), is included in each request to each downstream recipient.
- Verification and Processing:
- Upon receiving the rqJWT, each recipient verifies the signature of the embedded idJWT using the public key published on the domain of the initial requester. This ensures that the request originated from a trusted source at the time indicated and has not been tampered with during transmission.
- Additionally, the recipient verifies the signature of the rqJWT, which may have been generated by the 1st party or an intermediary. Once the signatures are verified, the recipient processes the request based on the information contained within the rqJWT.
- Generation of New rqJWT:
- Should a downstream recipient need to further propagate a request, they generate a new rqJWT which includes the idJWT they received as well as any additional information specific to their relationship with the downstream recipient.
This approach allows each downstream recipient to verify the authenticity of the original request and assures the integrity of the data deletion process, while adding any necessary additional information to the request before passing it on.
Each request needs to be an atomic unit, which can be individually processed by the recipient. The deletion request JWTs will include the following values:
| Field Name | Type | Description | Required |
| version | string | Version of the data format. | required |
| jti | string | The "jti" (JWT ID) claim provides a unique identifier for the JWT, serving as a global request identifier for tracking and managing the request throughout its lifecycle. | required |
| iss | string | The " iss " (issuer) claim identifies the principal that issued the JWT. It represents the eTLD+1 of the 1st party and can be used to locate their dsrdelete.json file. | required |
| sub | string | The " sub " (subject) claim identifies the principal that is the subject of the JWT. This field contains the identifier type and value of the identifier to which the deletion request applies. | required |
| iat | NumericDate | The "iat" (issued at) claim identifies the time at which the JWT was issued, representing the timestamp of the deletion request. | required |
| Field Name | Type | Description | Required |
| version | string | Version of the data format. | required |
| idJWT | string | The 1st party "identifier" JWT or idJWT. | required |
| jti | string | The "jti" (JWT ID) claim provides a unique identifier for the JWT, identifying the specific deletion request transaction. | required |
| iss | string | The " iss " (issuer) claim identifies the principal that issued the JWT. It represents the eTLD+1 of the requester, which can be used to locate their dsrdelete.json file. | required |
| sub | string | The " sub " (subject) claim identifies the principal that is the subject of the JWT. This field contains the identifier type and value of the identifier to which the deletion request applies. The value in this field may be the same as the value in the idJWT sub field or may be an intermediary’s alias for the original 1st party identifier. | required |
| iat | NumericDate | The "iat" (issued at) claim identifies the time at which the JWT was issued, representing the timestamp of the request transaction. | required |
| optionalParameters | string | A JSON object that contains optional parameters. The structure and content of this object are defined by the parties involved in transactions that utilize it. | optional |
| Field Name | Type | Description | Required |
| version | string | Version of the data format. | required |
| rqJWT | string | The requester “request” JWT or rqJWT. | required |
| jti | string | The "jti" (JWT ID) claim provides a unique identifier for the JWT, identifying the specific acknowledgment transaction. | required |
| iss | string | The " iss " (issuer) claim identifies the principal that issued the JWT. It represents the eTLD+1 of the recipient, which can be used to locate their dsrdelete.json file. | required |
| iat | NumericDate | The "iat" (issued at) claim identifies the time at which the JWT was issued, representing the timestamp of the acknowledgement transaction. | required |
| raResultCode | Numeric | A code indicating the request was successfully validated and accepted or identifying an error. | required |
| raResultString | string | Additional information related to the result, such as error details. | optional |
A data deletion request is accomplished by sending a POST request to the data deletion request API, which returns a response in JSON format. This protocol is implemented via a standard API and request format with a defined JSON payload as a JWT.
The following example includes a decoded idJWT to show the header & payload JSON.
{
"typ": "JWT",
"alg": "RS256",
"kid": "abc123"
}
.
{
"version": "1.0",
"jti": "unique_jwt_identifier",
"iss": "publisher1.com",
"sub": {
"identifierValue": "28f6dc889e...fe167",
"identifierType": "email",
"identifierFormat": "sha256"
},
"iat": 1693459424
}
The following example includes a decoded rqJWT to show the header & payload JSON.
{
"typ": "JWT",
"alg": "RS256",
"kid": "abc123"
}
.
{
"version": "1.0",
"idJWT": "original_jwt_information",
"jti": "unique_jwt_identifier",
"iss": "vendor1.com",
"sub": {
"identifierValue": "28f6dc889e...fe167",
"identifierType": "email",
"identifierFormat": "sha256"
}
"iat": 1693459424,
"optionalParameters": {optional_paramters_information}
}
The following example includes a decoded acJWT to show the header & payload JSON.
{
"typ": "JWT",
"alg": "RS256",
"kid": "abc123"
}
.
{
"version": "1.0",
"rqJWT": "original_jwt_information",
"jti": "6G7H8J",
"iss": "vendor2.com",
"iat": 1693459424,
"raResultCode": 4,
"raResultString": "Unsupported identifier type: phone"
}
When processing requests successfully, servers are expected to respond with an HTTP 202 status code, indicating the request was accepted. In cases where errors occur, servers should respond with an HTTP 400 status code, indicating failure. Additionally, along with the HTTP status code, recipients include a result code in the acJWT response payload raResultCode claim to provide further details about the outcome of the request. In addition to the result code, responses may also contain a string with additional details about the error in the acJWT raResultString claim.
For guidelines on error handling, please refer to the following table:
| Result Code | Description |
| 0 | Successful: Recipient has acknowledged successful receipt of the deletion request. |
| 1 | Malformed Request: The deletion request is missing required fields, leading to a malformed request. |
| 2 | Invalid Signature: The signature provided in the JWT token is invalid, indicating possible issues with key or algorithm. |
| 3 | Invalid JWT Token: The JWT token provided is structurally or cryptographically invalid. |
| 4 | Unsupported Identifier Type: The identifier type in the deletion request isn't supported by the recipient's configuration. |
| 5 | Incorrect Identifier Format: The identifier in the deletion request doesn't match the expected format. |
| 6 | Invalid Timestamp: Indicates that the timestamp provided in the JWT is invalid or expired. |
There are generally two classes of identifiers used in ad-interactions distinguished by access limitations: those which are directly accessible by 1st-parties and those which are only accessible to 3rd parties. The first class includes any identifiers available in the 1st-party context, including on web pages and 1st-party local storage. The second class includes identifiers maintained in protected 3rd-party storage, such as 3rd-party cookies. Probabilistic identifiers, which are based on constellations of data values, presumably may fall into the first, second or a combination of both classes, depending on how they are constructed.
The initial version of this proposal only provides support for identifiers a 1st-party has access to prior to initiating communication of the data deletion request. It is the responsibility of the 1st Party to determine what identifiers they must provide to which partners in deletion requests and to provide them in a form usable by those partners for satisfying the request.
The details of what identifiers a participant can accept and what format they can accept them in are provided by each participant in the dsrdelete.json file on their domain. Data deletion requests should contain the same identifiers sent to partners in data transactions. The 1st Party will gather this information from a partners dsrdelete.json files so that each request only includes a supported identifier.
To ensure deletion requests are legitimate and unmodified, participants will cryptographically sign requests and responses with private keys. The corresponding public keys will be published in their JWKS (JSON Web Key Set) files so that other participants can use them to verify signatures.
To accomplish this, this specification will use JSON Web Key Sets (JWKS). The JWKS standard ( RFC 7517 ) establishes a way to store and manage cryptographic keys as a set of JSON objects. JWKS supports asymmetric signature with a public key and private key pair, supporting the discoverability design of the dsrdelete.json file and the signature requirements of the data deletion framework.
For more information on JWKS format, please reference the following resources:
- IETF JWKS Standard: RFC 7517 - JSON Web Key Set (JWKS)
This specification defines a standard method by which participants communicate what information they require to execute data deletion requests and resources needed by other participants when interacting with them, such as cryptographic keys. To achieve this, there will be two options of discovery for participants. Both options are available to support multiple use-cases for discovery. To achieve this, participants will be required to create a dsrdelete.json file, which will be considered the authoritative version of a participant's information.
For easy access and discovery, participants must provide a JSON file named dsrdelete.json in the root of their domain. Parties supporting this standard would be expected to periodically read the files published by their partners and assure they support what is required by those partners in order to honor requests. Having participants publish this information directly on their domains allows them to fully and directly manage it, allows partners to work directly with them to resolve issues, and eliminates the potential for a single point of failure to disable communications.
1st Parties should read the data provided in the well-known resource from the vendor. This resource should include the following:
| Field Name | Type | Description | Required/Optional |
| endpoint | string | API endpoint for deletion requests. | Required |
| identifiers | Array of object | List of supported identifiers. | Required |
| publicKey | Array of object | Key format follows the IETF JSON Web Keys (JWK) Standard https://datatracker.ietf.org/doc/html/rfc7517 - reference the standard for key format. | Required |
| vendorScriptRequirement | boolean | True or false for requirement to use vendor script | Required |
| vendorScript | string | Optional field for vendors to publish a HTML code (e.g. a <script>) if this is needed to gather an identifier for a deletion request. | Optional |
https://www.publisher1.com/dsrdelete.json
{
"endpoint": "https://www.publisher1.com/api/delete/",
"identifiers": [
{ "id": 1, "type": "email", "format": "sha256" },
{ "id": 2, "type": "idfa", "format": "hash" }
],
"publicKey": [
{
"kty": "EC",
"crv": "P-256",
"x": "f83OJ3D2xF1Bg8vub9tLe1gHMzV76e8Tus9uPHvRVEU",
"y": "x_FEzRu9m36HLN_tue659LNpXW6pCyStikYjKIWI5a0",
"kid": "Public key used in JWS spec Appendix A.3 example"
}
],
"vendorScriptRequirement": true,
"vendorScript": "<script>.....</script>"
}
Participants that only support script based deletion requests, can do so by providing a property vendorScript along with a property vendorScriptRequirement in their dsrdelete.json file. A first party that wants to start the deletion process, will execute the script.
Note: Please note that supporting only script based deletion requests will limit the ability to receive deletion requests where requests are chained via endpoints.
An optional discovery method will be available via access to a directory provided by the Tech Lab. The directory would live in the Tech Lab tools portal and provide participants with the location of each dsrdelete.json resource. To create the directory entries, Tech Lab will crawl dsrdelete.json resources and automatically create entries–similar to ads.txt. The results would appear in the Tools Portal and in an API. Participants might use the directory to look up primary domains for companies that operate across multiple domains, validate a vendor has adopted the standard with the established request format, or to simplify a bulk lookup of endpoints from participants. All endpoints can be looked up, but not all endpoints need to be used.