Data Deletion Request Framework Updates #9
Conversation
Data Deletion Request Framework.md
Outdated
|
|
||
| <h4>Result Codes</h4> | ||
| <p>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.</p> | ||
| <p>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.</p> |
There was a problem hiding this comment.
The "oraResultCode" and "oraResultString" values are not defined in the acJWT. The original intent was for the raResultCode and raResultString ("ra" stands for Recipient Acknowledgement) to communicate either success or the first error encountered in processing the request. We assumed that recipients wouldn't continue processing the request once they determined it was invalid and so would only return one error code. I suggest we remove the addition starting at "Similarly, ...".
Suggested edits:
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. Recipients are only expected to report the first error encountered.
There was a problem hiding this comment.
Most of this makes sense to me. The last line that indicates that recipients are only expected to report the first error encountered I'd like to throw back to the WG to discuss.
| <p>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.</p> | ||
| <p>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.</p> | ||
| <p>For guidelines on error handling, please refer to the following table:</p> | ||
| <p>*Result code should be set in both rqaResultCode and oraResultCode |
There was a problem hiding this comment.
Think we should revisit the decision to include both rqaResultCode and oraResultCode. I think we would only ever receive one or the other and that we can define result codes for each or include a flag or some other means of indicating which JWT was the source of a returned error.
| <tr> | ||
| <td>1</td> | ||
| <td>Malformed Request: The deletion request is missing required fields, leading to a malformed request.</td> | ||
| <td><strong>Hosted JSON error:</strong> |
There was a problem hiding this comment.
I find "Hosted JSON Error" to be rather cryptic and I think lumping a bunch of error conditions behind a single code means there's going to need more detail provided, which is error prone. Suggest instead that we have separate codes for each of the identified error conditions.
Data Deletion Request Framework.md
Outdated
| <td>1</td> | ||
| <td>Malformed Request: The deletion request is missing required fields, leading to a malformed request.</td> | ||
| <td><strong>Hosted JSON error:</strong> | ||
| <p>Could not connect to the domain listed in <code>rqJWT/orJWT</code> iss claim: <code>{rqJT/orJWT iss}</code>.</p> |
There was a problem hiding this comment.
The second reference to rqJWT is misspelled (rqJT, missing the W). There are several other instances of this misspelling in the document.
| <tr> | ||
| <td>4</td> | ||
| <td>Unsupported Identifier Type: The identifier type in the deletion request isn't supported by the recipient's configuration.</td> | ||
| <td><strong>Malformed token:</strong> The <code>rqJWT/orJWT</code> is missing required claims, leading to a malformed request. Missing field detected: <code>{rqJT/orJWT field}</code></td> |
There was a problem hiding this comment.
I suggest we include separate codes for each missing field case in each JWT.
| <tr> | ||
| <td>2</td> | ||
| <td>Invalid Signature: The signature provided in the JWT token is invalid, indicating possible issues with key or algorithm.</td> | ||
| <td><strong>Invalid token:</strong> The <code>rqJWT/orJWT</code> could not be successfully decoded and parsed due to a structural invalidity. JSON token identifier: <code>{rqJT/orJWT jti}</code> </td> |
There was a problem hiding this comment.
I think we should only indicate the error encountered and not include the cause, so change the description to:
The
rqJWT/orJWTcould not be successfully decoded and parsed.
I think we should also have separate codes for each JWT.
| <tr> | ||
| <td>3</td> | ||
| <td>Invalid JWT Token: The JWT token provided is structurally or cryptographically invalid.</td> | ||
| <td><strong>Invalid token signature:</strong> The signature provided in the <code>rqJWT/orJWT</code> is invalid, indicating possible issues with the key or algorithm. JSON token identifier: <code>{rqJT/orJWT jti}</code></td> |
There was a problem hiding this comment.
I think we should only indicate the error encountered, so change description to:
The signature provided in the
rqJWT/orJWTcould not be verified."
I think we should have separate codes for each JWT and that we should consider having the recipient include information about the public key used in the attempt to validate the signature in the raResultString claim.
- 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
Corrected version
2 participants
This PR includes multiple updates to the framework. These updates are open for public comment until December 1, 2025. Comments may be provided by sending an email to [email protected] or as comments on this PR.
Changes
rqJWT.suband theidJWT.subclaim formats to provide additional clarity on these formats. Additionally, renamed theidJWTtoorJWT.publicKeywithjwksUrialgandkidparameters are requiredpollFrequencyto both thedsrdelete.jsonfile and thejwks.jsonfilesdsrdelete.jsonfileoptionalParametersto dsrdelete.json to support extensibilitydsrdeleteJsonUrifor partners with multiple domains who only wish for one to host the complete filepublishedJwksUrito encourage key rotation