Version 2.0#12

Open

lamrowena wants to merge 6 commits intomainfrom

Collaborator

lamrowena commented Apr 6, 2026

Version 2.0

Updates to the rqJWT.sub and the idJWT.sub claim formats to provide additional clarity on these formats. Additionally, renamed the idJWT to orJWT.
Multiple updates to provide key rotation guidance & improve framework security
- Replaced publicKey with jwksUri
- Specified that alg and kid parameters are required
- Added pollFrequency to both the dsrdelete.json file and the jwks.json files
- Updated example dsrdelete.json file
Updates to the result codes
Other additions including:
- Addition of optional optionalParameters to dsrdelete.json to support extensibility
- Addition of optional dsrdeleteJsonUri for partners with multiple domains who only wish for one to host the complete file
- Addition of optional publishedJwksUri to encourage key rotation

lamrowena added 6 commits

October 13, 2025 15:54


          Update Data Deletion Request Framework.md


          Update Data Deletion Request Framework.md

- Updated all instances of 'requestor' to 'requester' for consistency
- Updated remaining references of (idJWT) to (orJWT)
- Removed references to the 1st party ID
- Updated descriptions of Request JWT, Acknowledgement JWT, identityType, and identityFormat for clarity
- Updated descriptions to clarify the purpose and usage of the orJWT


          Update Data Deletion Request Framework.md

59fd649

Corrected version


          Update Data Deletion Request Framework.md

9ddaf3a

Further expansion of result codes to address public comment feedback.


          Update Data Deletion Request Framework.md

a92430a

Fixed typo


          Merge pull request #9 from lamrowena/ddrf-oct2025-updates

d1a37bb

Data Deletion Request Framework Updates

bmayd reviewed

View reviewed changes

Data Deletion Request Framework.md

    
                <li>

                  <strong>Request JWT (rqJWT):</strong>

                  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.&nbsp;</li>

                  The rqJWT includes the orJWT as a claim along with the identifier to which the deletion request applies and additional information needed to validate, authenticate and track the request. The originating 1st party will generate an rqJWT for each vendor they communicate a deletion request to. If vendors need to communicate the requests to partners they work with, they will generate an new rqJWT for each partner which includes a copy of the orJWT they received along with their identifier for the deletion request, which may be different from the identifier they received.&nbsp;</li>

bmayd Apr 8, 2026 •

edited

Loading

The sentence starting

If vendors need to communicate the requests...

includes the phrase

...they will generate an new rqJWT...

should be

...they will generate a new rqJWT...

(a not an).

bmayd reviewed

View reviewed changes

Data Deletion Request Framework.md

    
                  <strong>Verification and Processing</strong>:&nbsp;</li>

                <ol>

                  <li>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.&nbsp;</li>

                  <li>Upon receiving the rqJWT, each recipient verifies the signature of the embedded orJWT using the public key published on the domain of the 1st party from which the initial request was made. This ensures that the request originated from the claimed source at the time indicated and has not been tampered with during transmission. &nbsp;</li>

bmayd Apr 8, 2026

Instead of:

...published on the domain of the 1st party from which the initial request was made. This ensures...

...published on the domain of the 1st party which made the initial request. This verifies...

bmayd reviewed

View reviewed changes

Data Deletion Request Framework.md

    
                <ol>

                  <li>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.&nbsp;</li>

                  <li>Upon receiving the rqJWT, each recipient verifies the signature of the embedded orJWT using the public key published on the domain of the 1st party from which the initial request was made. This ensures that the request originated from the claimed source at the time indicated and has not been tampered with during transmission. &nbsp;</li>

                  <li>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.</li>

bmayd Apr 8, 2026

Change:

Once the signatures are verified, the recipient processes the request based on the information contained within the rqJWT.

to:

Once the signatures are verified, the recipient generates and returns an acJWT, then proceeds with processing of the request based on the information contained within the rqJWT.

bmayd reviewed

View reviewed changes

Data Deletion Request Framework.md

+                  <li>Should a downstream recipient need to further propagate a request, they generate a new rqJWT which includes the orJWT they received as well as any additional information specific to their relationship with the downstream recipient.&nbsp;</li>
                 </ol>
               </ol>
               <p>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.</p>

bmayd Apr 8, 2026

Change:

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.

to:

This approach allows each downstream recipient to verify the authenticity of the original request, ensuring the integrity of the data deletion process while allowing for partner relationship specific information to be included where necessary.

bmayd reviewed

View reviewed changes

Data Deletion Request Framework.md

               <p>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.</p>
-              <h2>Deletion Request Data</h2>
+              <h2 id="request-data">Deletion Request Data</h2>
               <p>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:</p>

bmayd Apr 8, 2026

Change:

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:

to:

Each deletion request is a self-contained, atomic unit which can be processed independently by a recipient. The deletion request JWTs are defined as follows:

bmayd reviewed

View reviewed changes

Data Deletion Request Framework.md

		@@ -242,15 +237,7 @@
		</a>" (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.</td>

bmayd Apr 8, 2026

Change:

... (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.

to:

... (issuer) claim contains the domain (eTLD+1) of the 1st party that created the orJWT. The domain is used both to indicate who originated the request and to enable downstream participates to locate the dsrdelete.json file of the originator.

bmayd reviewed

View reviewed changes

Data Deletion Request Framework.md

                     <tr>
                       <td>iat</td>
                       <td>NumericDate</td>
                       <td>The "iat" (issued at) claim identifies the time at which the JWT was issued, representing the timestamp of the deletion request.</td>

bmayd Apr 8, 2026 •

edited

Loading

Change:

The "iat" (issued at) claim identifies the time at which the JWT was issued, representing the timestamp of the deletion request.

to:

The "iat" (issued at) claim contains the orJWT timestamp which should accurately reflect the creation time of the JWT and the transaction chain.

bmayd reviewed

View reviewed changes

Data Deletion Request Framework.md

                     <tr>
                       <td>version</td>
                       <td>string</td>
                       <td>Version of the data format.</td>

bmayd Apr 8, 2026

Do we have a definition for the version of the data format for the JWTs? I think we may have assumed it was the spec version, but I don't think that makes sense since the spec will likely be updated independently from the JWT definitions and each of the JWT definitions could change at different rates than the others. I suggest we include the version number in the version field description for each of the JWTs. I suggest we set the orJWT and rqJWT to version "2.0" since they've both been changed in this update and set the version of the acJWT to 1.0 since it has not been changed since version 1.0 of the spec.

If there are updates to any of the JWTs in the future, we should change the versions of the modified JWTs and also bump the spec version.

bmayd reviewed

View reviewed changes

Data Deletion Request Framework.md

                     <tr>
                       <td>version</td>
                       <td>string</td>
                       <td>Version of the data format.</td>

bmayd Apr 8, 2026

Per the comment above, define the version of the rqJWT as 2.0 since it has been updated in this release of the spec.

bmayd reviewed

View reviewed changes

Data Deletion Request Framework.md

                     <tr>
                       <td>iat</td>
                       <td>NumericDate</td>
                       <td>The "iat" (issued at) claim identifies the time at which the JWT was issued, representing the timestamp of the request transaction.</td>

bmayd Apr 8, 2026 •

edited

Loading

Change:

The "iat" (issued at) claim identifies the time at which the JWT was issued, representing the timestamp of the request transaction.

to:

The "iat" (issued at) claim contains the rqJWT timestamp which should accurately reflect the creation time of the JWT and request transaction.

bmayd reviewed

View reviewed changes

Data Deletion Request Framework.md

                       <td>string</td>
                       <td>The "<a target="_blank" href="https://datatracker.ietf.org/doc/html/rfc7519#section-4.1.1">
                           <span style="color:rgb(17, 85, 204);">iss</span>
                         </a>" (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.</td>

bmayd Apr 8, 2026

Change:

(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.

to:

(issuer) claim contains the domain (eTLD+1) of the party that created the rqJWT. The domain is used both to indicate who made the request and to enable downstream participates to locate the dsrdelete.json file of the requester.

bmayd reviewed

View reviewed changes

Data Deletion Request Framework.md

+                    <tr>
+                    <td>identifierType</td>
+                    <td>string</td>
+                    <td>The type of identifier provided in the identifierValue field. The value in this field must match a type specified in the intended recipients' dsrdelete.json file.</td>

bmayd Apr 8, 2026

Change:

the intended recipients' dsrdelete.json file.

to:

the dsrdelete.json file of the recipient.

bmayd reviewed

View reviewed changes

Data Deletion Request Framework.md

+                    <tr>
+                    <td>identifierFormat</td>
+                    <td>string</td>
+                    <td>The format of the identifier provided in the identifierValue field. The value in this field must match a format specified in the intended recipients' dsrdelete.json file.</td>

bmayd Apr 8, 2026

Change:

the intended recipients' dsrdelete.json file.

to:

the dsrdelete.json file of the recipient.

bmayd reviewed

View reviewed changes

Data Deletion Request Framework.md

                     <tr>
                       <td>version</td>
                       <td>string</td>
                       <td>Version of the data format.</td>

bmayd Apr 8, 2026

Per comments above, define the version of the acJWT as 1.0 since it has not been updated in this release of the spec.

bmayd reviewed

View reviewed changes

Data Deletion Request Framework.md

                       <td>string</td>
                       <td>The "<a target="_blank" href="https://datatracker.ietf.org/doc/html/rfc7519#section-4.1.1">
                           <span style="color:rgb(17, 85, 204);">iss</span>
                         </a>" (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.

bmayd Apr 8, 2026

Change:

(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.

to:

(issuer) claim contains the domain (eTLD+1) of the party that created the acJWT. The domain is used both to indicate who acknowledged the request and to enable recipients of the acknowledgement to locate the dsrdelete.json file of the acknowledger.

bmayd reviewed

View reviewed changes

Data Deletion Request Framework.md

                     <tr>
                       <td>iat</td>
                       <td>NumericDate</td>
                       <td>The "iat" (issued at) claim identifies the time at which the JWT was issued, representing the timestamp of the acknowledgement transaction.</td>

bmayd Apr 8, 2026

Change:

The "iat" (issued at) claim identifies the time at which the JWT was issued, representing the timestamp of the acknowledgement transaction.

to:

The "iat" (issued at) claim contains the acJWT timestamp which should accurately reflect the creation time of the JWT and acknowledgement transaction.

bmayd reviewed

View reviewed changes

Data Deletion Request Framework.md

                       <td>required</td>
                     </tr>
                     <tr>
                       <td>raResultCode</td>

bmayd Apr 8, 2026

Do we need to make this "raResultCode" or could it just be "resultCode"?

bmayd reviewed

View reviewed changes

Data Deletion Request Framework.md

                     <tr>
                       <td>raResultCode</td>
                       <td>Numeric</td>
                       <td>A code indicating the request was successfully validated and accepted or identifying an error.</td>

bmayd Apr 8, 2026

Change:

A code indicating the request was successfully validated and accepted or identifying an error.

to:

A result code indicating the request was successfully received or identifying an error; see Result Codes, below.

I believe the link above needs to be updated for v2, I took it from v1.

bmayd reviewed

View reviewed changes

Data Deletion Request Framework.md

               <h5>Example Request with required parameters:</h5>
               <p>
-                <em>The following example includes a decoded idJWT to show the header &amp; payload JSON.</em>
+                <em>The following example includes a decoded orJWT to show the header &amp; payload JSON.</em>

bmayd Apr 8, 2026

Change:

The following example includes a decoded orJWT to show the header & payload JSON.

to:

The following is an example of an orJWT showing the header and payload JSON.

bmayd reviewed

View reviewed changes

Data Deletion Request Framework.md

		@@ -420,7 +417,7 @@
		<p>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. </p>

bmayd Apr 8, 2026

Change:

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.

to:

A data deletion request is made by sending a POST request with an rqJWT to the API endpoint defined in the dsrdelete.json of the intended recipient who will respond with an acJWT.

The link above to the dsrdelete.json will need to be verified.

bmayd reviewed

View reviewed changes

Data Deletion Request Framework.md

		@@ -420,7 +417,7 @@
		<p>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. </p>
		<h5>Example Request with required parameters:</h5>

bmayd Apr 8, 2026

Change:

Example Request with required parameters:

to:

Example orJWT with required parameters:

bmayd reviewed

View reviewed changes

Data Deletion Request Framework.md

               }
               ```
               <h5>Example Request including optional parameters:</h5>

bmayd Apr 8, 2026

Change:

Example Request including optional parameters:

to:

Example rqJWT including required and optional parameters:

bmayd reviewed

View reviewed changes

Data Deletion Request Framework.md

               <h5>Example Request including optional parameters:</h5>
               <p>
                 <em>The following example includes a decoded rqJWT to show the header &amp; payload JSON.</em>

bmayd Apr 8, 2026

Change:

The following example includes a decoded rqJWT to show the header & payload JSON.

to:

The following is an example of an rqJWT showing the header and payload JSON with including optional parameters.

bmayd reviewed

View reviewed changes

Data Deletion Request Framework.md

               .
               {
-                  "version": "1.0",
+                  "version": "2.0",

bmayd Apr 8, 2026

Per comments above, since the acJWT has not been modified in this update it should stay at version 1.0.

bmayd reviewed

View reviewed changes

Data Deletion Request Framework.md

               <h2>Identifiers</h2>
               <p>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.</p>
               <h5>Identifier Communication</h5>
               <p>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.&nbsp;</p>

bmayd Apr 9, 2026 •

edited

Loading

Change to:

In the current version, this standard only supports identifiers a 1st-party has access to prior to initiating communication of the data deletion request. It is the responsibility of 1st Parties to determine what identifiers must be provided to which partners in deletion requests and to provide them in a form those partners can use to execute the request. In general, data deletion requests should contain the same identifiers sent to partners in bid requests and data transactions.

bmayd reviewed

View reviewed changes

Data Deletion Request Framework.md

               <p>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.</p>
               <h5>Identifier Communication</h5>
               <p>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.&nbsp;</p>
               <p>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.</p>

bmayd Apr 9, 2026 •

edited

Loading

Change to:

The details of what identifiers a participant can accept and in what format are provided by each participant in the dsrdelete.json file hosted on their domain. 1st Parties should ensure they are providing identifiers that are formatted appropriately for each partner based on the definitions in the partner dsrdelete.json files.

bmayd reviewed

View reviewed changes

Data Deletion Request Framework.md

               <p>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.&nbsp;</p>
               <p>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.</p>
               <h2>Request/Response Signatures</h2>
               <p>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.</p>

bmayd Apr 9, 2026

Change to:

To enable participants to verify requests and responses are authorized and unmodified, JWTs are cryptographically signed using participant private keys prior to communication. The corresponding public keys needed to verify signatures are published in publicly available JWKS (JSON Web Key Set) files which are located using the jwksUri defined in the dsrdelete.json file hosted on the participant domain.

bmayd reviewed

View reviewed changes

Data Deletion Request Framework.md

               <h5>Identifier Communication</h5>
               <p>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.&nbsp;</p>
               <p>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.</p>
               <h2>Request/Response Signatures</h2>

bmayd Apr 9, 2026

Change:

Request/Response Signatures

to:

JWT Signatures

bmayd reviewed

View reviewed changes

Data Deletion Request Framework.md

               <p>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.</p>
               <h2>Request/Response Signatures</h2>
               <p>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.</p>
               <h5>Cryptographic Keys</h5>

bmayd Apr 9, 2026

Suggest removing this heading.

bmayd reviewed

View reviewed changes

Data Deletion Request Framework.md

               <h2>Request/Response Signatures</h2>
               <p>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.</p>
               <h5>Cryptographic Keys</h5>
               <p>To accomplish this, this specification will use JSON Web Key Sets (JWKS). The JWKS standard (<a target="_blank" href="https://datatracker.ietf.org/doc/html/rfc7517">

bmayd Apr 9, 2026

Change:

To accomplish this, this specification will use JSON Web Key Sets (JWKS). The

to:

JSON Web Key Sets (JWKS), defined in the

bmayd reviewed

View reviewed changes

Data Deletion Request Framework.md

               <p>To accomplish this, this specification will use JSON Web Key Sets (JWKS). The JWKS standard (<a target="_blank" href="https://datatracker.ietf.org/doc/html/rfc7517">
                   <span style="color:rgb(17, 85, 204);">RFC 7517</span>
-                </a>) 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.</p>
+                </a>) 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 <code>dsrdelete.json</code> file and the signature requirements of the data deletion framework.</p>

bmayd Apr 9, 2026

Change:

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.

to:

enable participants to store and manage public keys as a set of JSON objects. Using JWKS provides industry standard support for asymmetric signatures based on public/private key pairs and supports the discoverability design of the dsrdelete.json resource.

bmayd reviewed

View reviewed changes

Data Deletion Request Framework.md

                   <span style="color:rgb(17, 85, 204);">RFC 7517</span>
-                </a>) 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.</p>
+                </a>) 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 <code>dsrdelete.json</code> file and the signature requirements of the data deletion framework.</p>
+                <p>Note that while <a href="https://datatracker.ietf.org/doc/html/rfc7517">RFC 7517</a> lists the <code>"alg"</code> and the <code>"kid"</code> parameters as optional, they are required in the context of this framework to ensure all participants can easily locate verification keys.</p>

bmayd Apr 9, 2026

Change:

participants can easily locate verification keys.

to:

participants can easily identify keys needed to verify specific JWTs.

bmayd reviewed

View reviewed changes

Data Deletion Request Framework.md

                 </li>
               </ul>
               <h2>Discovery</h2>
               <p>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.</p>

bmayd Apr 10, 2026 •

edited

Loading

Change to:

To ensure participants are able to discover configuration information required to support this framework, all participants are required to maintain a publicly accessible file named dsrdelete.json in a "/.well-known/" directory (see RFC 8615: Well-Known Uniform Resource Identifiers (URIs)) on every domain that supports the framework. This file should contain well formed JSON and is the authoritative source of a participant information. 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.

bmayd reviewed

View reviewed changes

Data Deletion Request Framework.md

               <h2>Discovery</h2>
               <p>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.</p>
               <h4>dsrdelete.json resource</h4>
               <p>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.&nbsp;</p>

bmayd Apr 10, 2026

Suggest we remove this.

bmayd reviewed

View reviewed changes

Data Deletion Request Framework.md

               <p>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.</p>
               <h4>dsrdelete.json resource</h4>
               <p>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.&nbsp;</p>
               <p>1st Parties should read the data provided in the well-known resource from the vendor. This resource should include the following:</p>

bmayd Apr 10, 2026

Change to:

The dsrdelete.json should be well formed JSON and containing the following elements:

bmayd reviewed

View reviewed changes

Data Deletion Request Framework.md

		@@ -599,19 +695,31 @@
		<td>string</td>
		<td>API endpoint for deletion requests.</td>

bmayd Apr 10, 2026

I think we may want to require endpoint to be webhooks that accept POST requests and maybe encourage participants to support versioned URL paths to facilitate version updates.

bmayd reviewed

View reviewed changes

Data Deletion Request Framework.md

                       <td>Required</td>
+                    </tr>
+                     <tr>
+                      <td>pollFrequency</td>

bmayd Apr 10, 2026

Think we should change this to "minRefresh".

bmayd reviewed

View reviewed changes

Data Deletion Request Framework.md

+                     <tr>
+                      <td>pollFrequency</td>
+                      <td>number </td>
+                      <td>Polling frequency, in seconds</td>

bmayd Apr 10, 2026

Change to:

Minimum time in seconds to wait after a successful fetch before initiating the next fetch.

bmayd reviewed

View reviewed changes

Data Deletion Request Framework.md

                     <tr>
                       <td>identifiers</td>
                       <td>Array of object</td>
                       <td>List of supported identifiers.</td>

bmayd Apr 10, 2026 •

edited

Loading

Change to:

List of supported identifier types.

We don't describe what identifier types are or how they're defined or used anywhere in the document, I think we need to add a section for it.

bmayd reviewed

View reviewed changes

Data Deletion Request Framework.md

    
                      <td>Key format follows the IETF JSON Web Keys (JWK) Standard https://datatracker.ietf.org/doc/html/rfc7517 - reference the standard for key format.</td>

                      <td>jwksUri</td>

                      <td>string</td>

                      <td>Location of the JSON Web Key Set (JWKS) endpoint which contains the JWKS used to sign all issued JSON Web Tokens (JWTs).</td>

bmayd Apr 10, 2026

Change to:

The URI for the participant JSON Web Key Set (JWKS) (see RFC 7517: JSON Web Key (JWK)). The standard location is: https://{your-domain}/.well-known/jwks.json.

bmayd reviewed

View reviewed changes

Data Deletion Request Framework.md

                       <td>Required</td>
                     </tr>
+                    <tr>
+                      <td>publishedJwksUri</td>

bmayd Apr 10, 2026

We don't talk about this anywhere else in the document, I think we need a section to properly define it and describe how it is used. I think we should also consider making it required so that folks can easily determine if a key they have is expired or never existed.

bmayd reviewed

View reviewed changes

Data Deletion Request Framework.md

+                    <tr>
+                      <td>publishedJwksUri</td>
+                      <td>string</td>
+                      <td>Location of the endpoint which contains prior JWK sets that include previously active signing keys, to facilitate signature verification of tokens issued before key rotation.</td>

bmayd Apr 10, 2026

I think that in addition to having a file of expired keys we should consider allowing folks to indicate expired keys in their JWKS files, perhaps by replacing the actual key with "expired" and including an "expired" attribute which is a timestamp indicating when the key was expired.

bmayd reviewed

View reviewed changes

Data Deletion Request Framework.md

                       <td>Required</td>
                     </tr>
                     <tr>
                       <td>vendorScript</td>

bmayd Apr 10, 2026

I think we need to provide a better explanation for what vendor scripts are and and how they're used.

bmayd reviewed

View reviewed changes

Data Deletion Request Framework.md

		@@ -624,38 +732,77 @@
		<td>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.</td>

bmayd Apr 10, 2026

This should be required if vendorScriptRequirement is true. We also need better requirements for the scripts and to think about what damage they could do given that they're JavaScript we're asking websites to execute.

bmayd reviewed

View reviewed changes

Data Deletion Request Framework.md

+                    <tr>
+                      <td>dsrdeleteJsonUri</td>
+                      <td>string</td>
+                      <td>Optional field for partners with multiple domains who only wish for one to host the complete file.</td>

bmayd Apr 10, 2026

I think we should clarify that if this attribute exists, it should be the only one in the file and if this is the primary dsrdelete.json, it should not include this attribute.

bmayd reviewed

View reviewed changes

Data Deletion Request Framework.md

               https://www.publisher1.com/dsrdelete.json
               {
                   "endpoint": "https://www.publisher1.com/api/delete/",

bmayd Apr 10, 2026 •

edited

Loading

suggest we add "ddrf" to the example URL and standardize on "example.com" instead of "publisher1.com":

"endpoint": "https://www.example.com/ddrf/delete/"

bmayd reviewed

View reviewed changes

Data Deletion Request Framework.md

               {
                   "endpoint": "https://www.publisher1.com/api/delete/",
+                  "pollFrequency": "259200", // 30 days

bmayd Apr 10, 2026

Per comments elsewhere, a 30 day pollFrequency without an indication of when the resource is going to be updated could be problematic. Either the example poll frequency should be hours or last updated information should be included in the resource.

bmayd reviewed

View reviewed changes

Data Deletion Request Framework.md

                       { "id": 2, "type": "idfa", "format": "hash" }
                   ],
-                  "publicKey": [
+                  "jwksUri": "https://example.com/.well-known/iabtl/jwks.json",

bmayd Apr 10, 2026

Change to make it match existing standard practice of putting it in /.well-known/:

"jwksUri": "https://example.com/.well-known/jwks.json"

bmayd reviewed

View reviewed changes

Data Deletion Request Framework.md


		```
		https://www.publisher1.com/dsrdelete.json

bmayd Apr 10, 2026 •

edited

Loading

Think this should be removed. It it is kept I suggest we standardize on "example.com" instead of "publisher1.com" and it should be in .well-known:

https://www.example.com/.well-known/dsrdelete.json

bmayd reviewed

View reviewed changes

Data Deletion Request Framework.md

               {
                   "endpoint": "https://www.publisher1.com/api/delete/",
+                  "pollFrequency": "259200", // 30 days
                   "identifiers": [

bmayd Apr 10, 2026 •

edited

Loading

Per comments elsewhere, we don't really define "identifiers" anywhere or define requirements and describe how they are used.

bmayd reviewed

View reviewed changes

Data Deletion Request Framework.md

                 </table>
               </div>
-              <h4>Example Resource for dsrdelete.json:</h4>
+              <h4>Example Resource for example.com/.well-known/iabtl/dsrdelete.json:</h4>

bmayd Apr 10, 2026

Suggest we remove iabtl or include it in all the URLs.

example.com/.well-known/dsrdelete.json

bmayd reviewed

View reviewed changes

Data Deletion Request Framework.md

+              ```
+              {
+                  "pollFrequency": "604800", // 7 days

bmayd Apr 10, 2026

Per other comments, this should be hours or we should include an updated time in the JWKS resource.

bmayd reviewed

View reviewed changes

Data Deletion Request Framework.md

		```


		<h4>Implementing Script-based deletion requests</h4>

bmayd Apr 10, 2026

I think we need to take another pass on this, too little information for what could be very risky to support.

bmayd reviewed

View reviewed changes

Data Deletion Request Framework.md

    
                <strong>Note</strong>: Please note that supporting only script based deletion requests will limit the ability to receive deletion requests where requests are chained via endpoints.</p>

              <h4>Directory</h4>

              <p>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.</p>

              <p>An optional discovery method will be available via access to a directory provided by the Tech Lab. The directory is available in the <a href="https://tools.iabtechlab.com/transparencycenter/explorer/business/datadeletionregistry">Tech Lab tools portal</a> 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.</p>

bmayd Apr 10, 2026

Change:

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.

to:

and provides participants with the URLs of dsrdelete.json resources listed by domain. Participants can use the directory to look up primary domains for companies that operate across multiple domains, determine if a vendor has adopted the standard or facilitate a bulk lookup of participants endpoints.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet