Unify Error Handling Language

[Wind4Greg]

To unify error handling language across this specification (and if desired other cryptosuite specifications) I'd recommend:

1. Use appropriate error handling language as in DI specification, e.g., "an error MUST be raised and SHOULD convey an error type of ERROR_CODE_NAME." where ERROR_CODE_NAME is defined in the DI specification.
2. Use standardized error codes from DI Specification, and if needed add new codes to DI specification
3. Check for non-rigorous error handling language and if it needs to be updated (errors without codes that need codes)

Below I show codes used but not in the DI specification and error conditions without codes. Thoughts/Opinions?

Error Codes Used but Not in DI Spec

1. INVALID_PROOF_CONFIGURATION used in 3.2.5 Proof Configuration (ecdsa-rdfc-2019), 3.3.5 Proof Configuration (ecdsa-jcs-2019), and 3.6.4 Base Proof Configuration (ecdsa-sd-2023)
2. INVALID_PROOF_DATETIME used in 3.2.5 Proof Configuration (ecdsa-rdfc-2019), 3.3.5 Proof Configuration (ecdsa-jcs-2019), and 3.6.4 Base Proof Configuration (ecdsa-sd-2023)

Errors without Codes

These seemed to me to need codes and rigorous handling. Line numbers are approximate. Need to assign to existing error codes or come up with new codes.

• line 1782: "the JSON pointer does not match the given |document|."
• line 2201: "Ensure the |proofValue| string starts with u, indicating that it is a multibase-base64url-no-pad-encoded value, throwing an error ";
• line 2209: "Ensure that the |decodedProofValue| starts with the ECDSA-SD base proof header bytes 0xd9, 0x5d, and 0x00, throwing an error if it does not."
• line 2214: "Ensure the result is an array of five elements."
• line 2472: "Ensure the |proofValue| string starts with u, indicating that it is a multibase-base64url-no-pad-encoded value, throwing an error if it does not."
• line 2480: "Ensure that the |decodedProofValue| starts with the ECDSA-SD disclosure proof header bytes 0xd9, 0x5d, and 0x01, throwing an error if it does not."
• line 2486: "Ensure the result is an array of five elements: a byte array of length 64, a byte array of length 36, an array of byte arrays, each of length 64, a map of integers to byte arrays of length 32, and an array of integers, throwing an error if not."
• line 2938: "If the length of |signatures| does not match the length of |nonMandatory|, throw an error indicating that the signature count does not match the non-mandatory message count."

[Wind4Greg]

Recommendation: Add INVALID_PROOF_CONFIGURATION, INVALID_PROOF_DATETIME, PROOF_TRANSFORMATION_ERROR, and MALFORMED_PROOF_ERROR to the VC-DI spec as the first three are are used in multiple cryptosuite specs and I propose that we use the MALFORMED_PROOF_ERROR for many ECDSA-SD errors and BBS errors. See below for details.

Error Codes Used but Not in DI Spec

1. INVALID_PROOF_CONFIGURATION used in 3.2.5 Proof Configuration (ecdsa-rdfc-2019), 3.3.5 Proof Configuration (ecdsa-jcs-2019), and 3.6.4 Base Proof Configuration (ecdsa-sd-2023)
2. INVALID_PROOF_DATETIME used in 3.2.5 Proof Configuration (ecdsa-rdfc-2019), 3.3.5 Proof Configuration (ecdsa-jcs-2019), and 3.6.4 Base Proof Configuration (ecdsa-sd-2023)
3. PROOF_TRANSFORMATION_ERROR used in 3.2.3 Transformation (ecdsa-rdfc-2019), 3.3.3 Transformation (ecdsa-jcs-2019), and 3.3.3 Transformation (ecdsa-jcs-2019)

Errors without Codes Suggested Assignments

• line 1782: "the JSON pointer does not match the given |document|." From section selectPaths. This is used behind the scenes when creating SD base proof or derived proof. It is not used in verification. I would recommend using INVALID_PROOF_CONFIGURATION error here.

The rest of these errors could be grouped under the general category of a MALFORMED_PROOF_ERROR:

• line 2201: "Ensure the |proofValue| string starts with u, indicating that it is a multibase-base64url-no-pad-encoded value, throwing an error ";
• line 2209: "Ensure that the |decodedProofValue| starts with the ECDSA-SD base proof header bytes 0xd9, 0x5d, and 0x00, throwing an error if it does not."
• line 2214: "Ensure the result is an array of five elements."
• line 2472: "Ensure the |proofValue| string starts with u, indicating that it is a multibase-base64url-no-pad-encoded value, throwing an error if it does not."
• line 2480: "Ensure that the |decodedProofValue| starts with the ECDSA-SD disclosure proof header bytes 0xd9, 0x5d, and 0x01, throwing an error if it does not."
• line 2486: "Ensure the result is an array of five elements: a byte array of length 64, a byte array of length 36, an array of byte arrays, each of length 64, a map of integers to byte arrays of length 32, and an array of integers, throwing an error if not."
• line 2938: "If the length of |signatures| does not match the length of |nonMandatory|, throw an error indicating that the signature count does not match the non-mandatory message count."

[msporny]

PRs w3c/vc-data-integrity#274 and #64 have been merged to address this issue, closing.