- Error handling and messaging in the vc-api is designed in accordance with [RFC 9457](https://www.rfc-editor.org/rfc/rfc9457.html). - Implementers SHOULD include a [status](https://www.rfc-editor.org/rfc/rfc9457.html#name-status) and a [title](https://www.rfc-editor.org/rfc/rfc9457.html#name-title) - in the error response in accordance with the specifics of the endpoints on which the error occurs. - Other fields such as [detail](https://www.rfc-editor.org/rfc/rfc9457.html#name-detail), [instance](https://www.rfc-editor.org/rfc/rfc9457.html#name-instance) and - [type](https://www.rfc-editor.org/rfc/rfc9457.html#name-type) are encouraged to be leveraged to provide more contextual feedback about the error, + Error handling and messaging in the VC-API follows [RFC 9457](https://www.rfc-editor.org/rfc/rfc9457.html). + Implementers SHOULD include a [status](https://www.rfc-editor.org/rfc/rfc9457.html#name-status) + and a [title](https://www.rfc-editor.org/rfc/rfc9457.html#name-title) + in the error response body relating to the specifics of the endpoint on which the error occurs. +
+
+ Aligning on error handling and messaging will greatly improve test-suites accuracy + when identifying interoperability technical friction. +
+ + Other fields such as [detail](https://www.rfc-editor.org/rfc/rfc9457.html#name-detail), + [instance](https://www.rfc-editor.org/rfc/rfc9457.html#name-instance) + and [type](https://www.rfc-editor.org/rfc/rfc9457.html#name-type) + are encouraged to be leveraged to provide more contextual feedback about the error, while being conscious of not disclosing sensitive information for security concerns.- Implementers SHOULD catch all server errors in the best of their capabilities. - Endpoints should avoid returning improperly handled 500 errors in a production environment leading to potential [information disclosure](https://owasp.org/www-community/Improper_Error_Handling). + Implementers should try to handle all server errors in the best of their capabilities. + Endpoints should avoid returning improperly handled 500 errors in a production + environment leading to potential [information disclosure](https://owasp.org/www-community/Improper_Error_Handling).
-- While performing verification of a credential and/or presentation, an implementer might be in a situation where they must raise an error. - This is an ambigous case between http protocol related errors and VC specification related errors. - Given a verifiableCredential: - For cases where the data model is wrong or the proof is invalid, a 400 invalid input should be returned. - For cases where the a verificaiton method cannot be resolved, a 404 missing ressource should be returned. - For cases where the validity is bad or the status is invalid, a 422 unprocessable entity should be returned, - meaning the verifier has no intention to process the credential further. - - The logic is to differentiate between a verifier's verification processes and validation processes. - - As thus, the following mapping of status and title should be applied: - - For data model errors, return 400: Data Model - - For malformed proof, return 400: Proof Malformed - - For invalid proof, return 422: Proof Invalid - - For invalid credential/presentation, return 422: Validity Period - - For failed status checks, return 422: Status Invalid + While performing [verification](https://w3c.github.io/vc-data-model/#verification), + an implementer should avoid raising errors and instead gather + [ProblemDetails](https://w3c.github.io/vc-data-model/#problem-details) + objects to include in the verification results.
-
+ {
+ "verified": false,
+ "document": {},
+ "mediaType": "",
+ "controller": "",
+ "controllerDocument": {},
+ "warnings": [ProblemDetails],
+ "errors": [ProblemDetails]
+ }
+