w3c-ccg
How to structure response metadata for `/credentials/verify` and `/presentations/verify` to include challenge verification metadata?
How should the current response format for the above endpoints {checks, warnings, errors} be restructured to contain some variant of challengeVerificationMetadata: {uses, verified, firstVerified}?
The group discussed this on the 2024-05-28 telecon:
@jandrieu noted that we post the current format in this conversation. The current format is specified here: https://github.com/w3c-ccg/vc-api/blob/main/components/VerifyCredentialResult.yml
@dlongley noted that this part of the specification is very under specified. It's not clear how useful these structures are. @jandrieu thinks we need to restructure it, response should label itself... "These are the checks, these are the results of those checks". @dlongley agreed, "checks, warnings, and errors" are not bound to each other very well. Should be structured better -- whether an error is treated as a warning is a business rule -- provide all data to perform analysis. @PatStLouis noted that it's related to the ErrorDetails definition he's working on, but there is more work to be done here. @dlongley agreed that errors are protocol related (HTTP Errors), share as much as we can, includes "warnings" -- don't know how valuable that is (re-use old object for that), might need to figure out if all implementations need to behave the same, do we error on first error, or wait for all errors? In either case, lists all checks and any errors associated (might want every implementation to work that way) -- don't know level of prescriptive or not we want to be right now. @PatStLouis noted if you are verifying a VC, verify the proof (HTTP 422 -- unprocessable content, proof didn't verify?), do we want to match verification to existing status codes or is verifying a VC different enough that we would make our own error objects. @dlongley noted that it gets challenging when you verify more than one proof and one proof fails but the other does not. @PatStLouis wondered if we can start with one property and go from there. @dlongley suggested we figure out what the "minimum viable return value" would be. @PatStLouis would like to have just a "verified: true/false" if everything passed, false otherwise.
The group didn't think this was ready for a PR just yet and needed more work to figure out the details. We do know that the current setup of "checks/warnings/errors" is too ambiguous and needs to be fixed/changed.
The group discussed this briefly on the 2024-06-18 call, but decided to wait for more people to be present to process it further.