From 5871711d153c28dbcfc6f555b1a54f5b145f9044 Mon Sep 17 00:00:00 2001 From: lamrowena <108421200+lamrowena@users.noreply.github.com> Date: Mon, 13 Oct 2025 15:54:58 -0400 Subject: [PATCH 1/3] Update Data Deletion Request Framework.md --- Data Deletion Request Framework.md | 239 +++++++++++++++++++---------- 1 file changed, 158 insertions(+), 81 deletions(-) diff --git a/Data Deletion Request Framework.md b/Data Deletion Request Framework.md index 61693cf..3041083 100644 --- a/Data Deletion Request Framework.md +++ b/Data Deletion Request Framework.md @@ -18,6 +18,11 @@ 1.0 Version 1.0 released + +October 2025 +1.1 +Version 1.1 open for public comment + @@ -94,18 +99,18 @@

JSON Web Token (JWT) Implementation

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:

+

The specification delineates three distinct JWTs: an originating requester JWT (orJWT), a request JWT (rqJWT), and an acknowledgment JWT (acJWT). Each serves a unique purpose as described below:

  1. - 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.
    2. + Originating Requestor JWT (idJWT): Generated by the 1st party, this orJWT 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.
  2. 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. 
    3. + The rqJWT includes the orJWT 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 orJWT they received. 
  3. 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.

+

This model ensures that all recipients can employ the shared orJWT 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) @@ -120,38 +125,28 @@

  1. - *Data Subject - requests a data deletion from a 1st Party*
    2. + *Data Subject requests a data deletion from a 1st Party*
    1. 1st Party validates the request.
    2. 1st Party determines what identifiers are subject to the request.
    3. 1st Party determines partners that data has been shared with which the request must be communicated to.
    4. 1st party accesses the dsrdelete.json resource of each identified partner to determine how IDs must be formatted for them. 
      5. -
    5. 1st party generates an initial idJWT for each identifier that is subject to the request.
      6. +
    6. 1st party generates an initial orJWT for each identifier that is subject to the request.
  2. - 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 - + Requester generates a deletion packet formatted as a rqJWT which includes the orJWT created in step 1.5, as well as the other values described under Request Data below.
  3. - Requester - sends the rqJWT to the Recipient.
    4. + Requester sends the rqJWT to the Recipient.
  4. - 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. 
    5. + Recipient receives the rqJWT and verifies the signatures of the orJWT and rqJWT using public keys published on the 1st party and requester’s respective domains. 
  5. - 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.
    6. + 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.
  6. - 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.
    7. + 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.
  7. - *Requester - logs the Recipient Acknowledgement acJWT.*
    8. + *Requester logs the Recipient Acknowledgement acJWT.*
  8. *Recipient logs the request rqJWT.*
    9. @@ -161,7 +156,7 @@
    1. Determining what partners the request must be forwarded to.
    2. Accessing the dsrdelete.json resource for each partner to determine how IDs must be formatted for them. 
      3. -
    3. Generating rqJWTs to be sent to partners using the original identifier idJWT they received and by following steps 2 through 8 above.  
      4. +
    4. Generating rqJWTs to be sent to partners using the original orJWT they received and by following steps 2 through 8 above.  
  9. *Recipient, in a separate flow, executes the data deletion.*
    10. @@ -172,27 +167,27 @@
  10. Step 1 and Steps 7-10.

    11. JSON Web Token (JWT) Propagation

    -

    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.

    +

    When a deletion request needs to be propagated to downstream recipients, orJWTs are included in the rqJWT to ensure integrity and authenticity of the original request. Each downstream recipient receives the orJWT 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:

    1. - Inclusion of Original idJWT: The original idJWT, generated by the initial requester (1st Party), is included in each request to each downstream recipient.
      2. + Inclusion of orJWT: The orJWT, generated by the initial requester (1st Party), is included in each request to each downstream recipient.
    2. Verification and Processing: 
        3. -
      1. 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. 
        2. +
      2. Upon receiving the rqJWT, each recipient verifies the signature of the embedded orJWT 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. 
      3. 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.
    3. Generation of New rqJWT: 
        4. -
      1. 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. 
        2. +
      2. 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. 

    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.

    -

    Deletion Request Data

    +

    Deletion Request Data

    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:

    -
    idJWT: Issuer “identifier” JWT 
    +
    orJWT: Originating Requester JWT 
    @@ -242,14 +237,6 @@ " (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. - - - - - - @@ -292,9 +279,9 @@ - + - + @@ -316,12 +303,22 @@ - - - - + + + + + + + + + + + + + + + + @@ -420,7 +417,7 @@

    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. 

    Example Request with required parameters:

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

    ``` @@ -434,11 +431,6 @@ "version": "1.0", "jti": "unique_jwt_identifier", "iss": "publisher1.com", - "sub": { - "identifierValue": "28f6dc889e...fe167", - "identifierType": "email", - "identifierFormat": "sha256" - }, "iat": 1693459424 } ``` @@ -458,13 +450,12 @@ . { "version": "1.0", - "idJWT": "original_jwt_information", + "orJWT": "base64url_header.base64url_payload.base64url_signature", "jti": "unique_jwt_identifier", "iss": "vendor1.com", - "sub": { - "identifierValue": "28f6dc889e...fe167", - "identifierType": "email", - "identifierFormat": "sha256" + "identifierValue": "28f6dc889e...fe167", + "identifierType": "email", + "identifierFormat": "sha256" }, "iat": 1693459424, "optionalParameters": {optional_parameters_information} @@ -489,14 +480,18 @@ "jti": "6G7H8J", "iss": "vendor2.com", "iat": 1693459424, - "raResultCode": 4, - "raResultString": "Unsupported identifier type: phone" + "rqaResultCode": 2, + "rqaResultString": "Invalid token" + "oraResultCode": 2, + "oraResultString": "Invalid token" } ```

    Result Codes

    -

    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.

    +

    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. Similarly, responses must include an oraResultCode claim, which serves the same purpose for operations at the orginating request level. An accompanying oraResultString claim may also be provided to supply additional descriptive information.

    For guidelines on error handling, please refer to the following table:

    +

    *Result code should be set in both rqaResultCode and oraResultCode +

    **Result code only applies to rqJWT

    required
    substringThe " - 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 NumericDaterequired
    idJWTorJWT stringThe 1st party "identifier" JWT or idJWT.The 1st party "originating requester" JWT or orJWT. required
    required
    substringThe " - 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.requiredidentifierValuestringThe value of the identifier to which the deletion request applies.required
    identifierTypestringThe type of identifier to which the deletion request applies.The value in this field must be of a type as specified in the intended recipients' dsrdelete.json file.required
    identifierFormatstringThe format of identifier to which the deletion request applies.required
    iat
    @@ -514,31 +509,59 @@ - + - + - + - + - + - + - - + + + + + + + + + + + + + + + + + +
    0Successful: Recipient has acknowledged successful receipt of the deletion request.Successful: Recipient has acknowledged successful receipt of the deletion request.
    1Malformed Request: The deletion request is missing required fields, leading to a malformed request.Hosted JSON error: +

    Could not connect to the domain listed in rqJWT/orJWT iss claim: {rqJT/orJWT iss}.

    +

    Could not find the dsrdelete.json file for the rqJWT/orJWT issuer: {rqJT/orJWT iss}.

    +

    Could not find the jwksUri entry in the dsrdelete.json for the rqJWT/orJWT issuer: {rqJT/orJWT iss}.

    +

    Could not find the keys file: {rq/or dsrdelete.json jwksUri} identified in the jwksUri entry in the dsrdelete.json for the rqJWT/orJWT issuer: {rqJT/orJWT iss}.

    +

    Could not find the key with kid: {rqJT/orJWT kid} in keys file identified: {rq/or dsrdelete.json jwksUri} identified in the jwksUri entry in the dsrdelete.json for the rqJWT/orJWT issuer: {rqJT/orJWT iss}.

    +

    Request kid: {rqJT/orJWT kid} alg claim: {rqJT/orJWT alg} does not match the alg claim: {key file alg} in the keys file: {rq/or dsrdelete.json jwksUri} for the kid.
    2Invalid Signature: The signature provided in the JWT token is invalid, indicating possible issues with key or algorithm.Invalid token: The rqJWT/orJWT could not be successfully decoded and parsed due to a structural invalidity. JSON token identifier: {rqJT/orJWT jti}
    3Invalid JWT Token: The JWT token provided is structurally or cryptographically invalid.Invalid token signature: The signature provided in the rqJWT/orJWT is invalid, indicating possible issues with the key or algorithm. JSON token identifier: {rqJT/orJWT jti}
    4Unsupported Identifier Type: The identifier type in the deletion request isn't supported by the recipient's configuration.Malformed token: The rqJWT/orJWT is missing required claims, leading to a malformed request. Missing field detected: {rqJT/orJWT field}
    5Incorrect Identifier Format: The identifier in the deletion request doesn't match the expected format.

    Invalid token timestamp: The timestamp provided in the rqJWT/orJWT is invalid: {rqJT/orJWT timestamp}. The timestamp is {relevant error case}.

    +

    Relevant error cases:

    +
      +
    • timestamp value which is not a positive integeer +
    • too far in the future: issued more than 5 minutes ahead of token receipt +
    +
    6Invalid Timestamp: Indicates that the timestamp provided in the JWT is invalid or expired.6*Non-sequential token timestamp: The timestamp of rqJWT: {rqJWT timestamp} precedes the timestamp of orJWT: {orJWT timestamp}
    7**Unsupported identifier type: The identifier type in the rqJWT: {rqJT identifierType} isn't supported.
    8**Unsupported identifier format: The identifier format in the rqJWT {rqJT identifierFormat} isn’t supported.
    9**Incorrect identifier format: The identifier format in the rqJWT: {rqJT identifierFormat} does not match the format of the received rqJWT‘s identifierValue.
    10**Invalid identifier value: The identifier value in the rqJWT is invalid (e.g. incorrect length).
    @@ -553,7 +576,10 @@
    Cryptographic Keys

    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.

    + ) 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.

    +

    Note that while RFC 7517 lists the "alg" and the "kid" parameters as optional, they are required in the context of this framework.

    +
    Key Rotation and Caching
    +

    Participants must support key rotation to maintain secure and reliable verification. Implementations should maintain a local cache of each participant's JWKS. Participants must refresh their cached JWKS according to the pollFrequency. When verifying a signed request, if a referenced key ID (kid) cannot be found in the cached key set, the participant must fetch a new copy of the requestor's JWKS from the jwksUri location and update its cache accordingly.

    JWKS Resources

    For more information on JWKS format, please reference the following resources:

    -

    Example Resource for dsrdelete.json:

    +

    Example Resource for example.com/.well-known/iabtl/dsrdelete.json:

    ``` https://www.publisher1.com/dsrdelete.json { "endpoint": "https://www.publisher1.com/api/delete/", + "pollFrequency": "259200", // 30 days "identifiers": [ { "id": 1, "type": "email", "format": "sha256" }, { "id": 2, "type": "idfa", "format": "hash" } ], - "publicKey": [ + "jwksUri": "https://example.com/.well-known/iabtl/jwks.json", + "vendorScriptRequirement": true, + "vendorScript": "" +} +``` + +

    Example Resource for example.com/.well-known/iabtl/jwks.json

    + +``` +{ + "pollFrequency": "604800", // 7 days + "keys": [ { "kty": "EC", + "alg": "ES256", + "crv": "P-256", + "x": "8PdtOAYA6bYKVDWZ16kzAlQkS9JEZakZ3rmXbzIl0nk", + "y": "D2qikPEHzo6Q9qLghINZ5nO8u8zjcRNbZnbW7M6pJr0", + "kid": "unique_identifier_for_1st_key" + + }, + { + "kty": "EC", + "alg": "ES256", "crv": "P-256", - "x": "f83OJ3D2xF1Bg8vub9tLe1gHMzV76e8Tus9uPHvRVEU", - "y": "x_FEzRu9m36HLN_tue659LNpXW6pCyStikYjKIWI5a0", - "kid": "Public key used in JWS spec Appendix A.3 example" + "x": "RyIDwX4y7tkctGt65W0WaslpQ9j9AnHcUiKhsKrcMWw", + "y": "kRbxhHFRLjd75Xa3Ds_U196o4lBHWkhyq-YKoCQPAfU", + "kid": "unique_identifier_for_2nd_key" + }, + { + "kty": "EC", + "alg": "ES256", + "crv": "P-256", + "x": "SLvexvatx17wweJkO4GwhOKaa_Z7DViYarzpLIAl3dE", + "y": "SgP1HvjKhhqQ8nqpAKTD_WBq6EcBt40jRsbbXRfjU7E", + "kid": "unique_identifier_for_3rd_key" } - ], - "vendorScriptRequirement": true, - "vendorScript": "" + ] } ``` -

    Implementing Script-based deletion requests

    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.

    Directory

    -

    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.

    +

    An optional discovery method will be available via access to a directory provided by the Tech Lab. The directory is available 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.

    From 99329287623c7b4038d167eb128c2ae24c6aa44e Mon Sep 17 00:00:00 2001 From: lamrowena <108421200+lamrowena@users.noreply.github.com> Date: Wed, 22 Oct 2025 15:04:51 -0400 Subject: [PATCH 2/3] 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 --- Data Deletion Request Framework.md | 20 ++++++++++---------- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/Data Deletion Request Framework.md b/Data Deletion Request Framework.md index 3041083..07985c6 100644 --- a/Data Deletion Request Framework.md +++ b/Data Deletion Request Framework.md @@ -102,15 +102,15 @@

    The specification delineates three distinct JWTs: an originating requester JWT (orJWT), a request JWT (rqJWT), and an acknowledgment JWT (acJWT). Each serves a unique purpose as described below:

    1. - Originating Requestor JWT (idJWT): Generated by the 1st party, this orJWT 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.
      2. + Originating Requester JWT (orJWT): the orJWT is generated by the 1st party and includes information used to identify the origin of the deletion request. It's purpose is to provide, through a cryptograph signature, a verifiable proof that the request was generated by the originating party and hasn't been tampered with.
    2. Request JWT (rqJWT): - The rqJWT includes the orJWT 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 orJWT they received. 
      3. + 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. 
    3. 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 orJWT 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.

    +

    This model ensures all recipients are able validate and authenticate that the request originated with the claimed 1st party by verifying the orJWT signature using public keys retrieved from the originating domain. In addition, all recipients are able to verify the requests they receive originated with the claimed requester by verifying the rqJWT signature using public keys retrieved from the requester domain. Lastly, recipients are able to provide requesters with proof of the deletion request transaction and the success or failure of its communication with the acJWT signature that can be verified using public keys retrieved from the recipient domain.

    For detailed information on JWT implementation, please refer to: IETF RFC 7519 - JSON Web Tokens (JWT) @@ -131,7 +131,7 @@

  11. 1st Party determines what identifiers are subject to the request.
  12. 1st Party determines partners that data has been shared with which the request must be communicated to.
  13. 1st party accesses the dsrdelete.json resource of each identified partner to determine how IDs must be formatted for them. 
    14. -
  14. 1st party generates an initial orJWT for each identifier that is subject to the request.
    15. +
  15. 1st party generates an orJWT for the request.
  • @@ -175,7 +175,7 @@
  • Verification and Processing: 
      • -
    1. Upon receiving the rqJWT, each recipient verifies the signature of the embedded orJWT 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. 
      2. +
    2. 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.  
    3. 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.
  • @@ -311,13 +311,13 @@ identifierType string - The type of identifier to which the deletion request applies.The value in this field must be of a type as specified in the intended recipients' dsrdelete.json file. + 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. required identifierFormat string - The format of identifier to which the deletion request applies. + The format of the identifier provided in the identifierValue field. The valur in this field must match a format specified in the intended recipients' dsrdelete.json file. required @@ -488,7 +488,7 @@ ```

    Result Codes

    -

    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. Similarly, responses must include an oraResultCode claim, which serves the same purpose for operations at the orginating request level. An accompanying oraResultString claim may also be provided to supply additional descriptive information.

    +

    When requests are processed successfully, recipients are expected to respond with an HTTP 202 status code indicating the request was accepted. In cases where an error is encountered, recipients should respond with an HTTP 400 status code to indicate the failure. Additionally, recipients should include the defined Result Code of the error encountered in the acJWT response payload raResultCode claim and optionally 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 should be set in both rqaResultCode and oraResultCode

    **Result code only applies to rqJWT

    @@ -514,7 +514,7 @@ 1 Hosted JSON error: -

    Could not connect to the domain listed in rqJWT/orJWT iss claim: {rqJT/orJWT iss}.

    +

    Could not connect to the domain listed in rqJWT/orJWT iss claim: {rqJWT/orJWT iss}.

    Could not find the dsrdelete.json file for the rqJWT/orJWT issuer: {rqJT/orJWT iss}.

    Could not find the jwksUri entry in the dsrdelete.json for the rqJWT/orJWT issuer: {rqJT/orJWT iss}.

    Could not find the keys file: {rq/or dsrdelete.json jwksUri} identified in the jwksUri entry in the dsrdelete.json for the rqJWT/orJWT issuer: {rqJT/orJWT iss}.

    @@ -579,7 +579,7 @@     ) 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.

    Note that while RFC 7517 lists the "alg" and the "kid" parameters as optional, they are required in the context of this framework.

    Key Rotation and Caching
    -

    Participants must support key rotation to maintain secure and reliable verification. Implementations should maintain a local cache of each participant's JWKS. Participants must refresh their cached JWKS according to the pollFrequency. When verifying a signed request, if a referenced key ID (kid) cannot be found in the cached key set, the participant must fetch a new copy of the requestor's JWKS from the jwksUri location and update its cache accordingly.

    +

    Participants must support key rotation to maintain secure and reliable verification. Implementations should maintain a local cache of each participant's JWKS. Participants must refresh their cached JWKS according to the pollFrequency. When verifying a signed request, if a referenced key ID (kid) cannot be found in the cached key set, the participant must fetch a new copy of the requester's JWKS from the jwksUri location and update its cache accordingly.

    JWKS Resources

    For more information on JWKS format, please reference the following resources: