Error Handling in Veramo Credential-w3c package.

Is your feature request related to a problem? Please describe. We are working heavily with the Veramo credential-w3c package and whenever we try to verify a presentation which is created with a broken credential for example with invalid issuance date or expiration date, we do not receive the error for why it failed and only receive a boolean stating false.

Describe the solution you’d like We would like to see the reason for why the verification failed as well. To find out what is broken in the credential or the verifiable presentation.

Additional context Code snippet where the error needs to be returned.

try { 
    const verification = await verifyPresentationJWT(jwt, resolver, {
      challenge: args.challenge,
      domain: args.domain,
      audience,
    })
    return true
} catch (e: any) {
    //TODO: return a more detailed reason for failure
    return false
}

[mirceanis]

You are right, a simple boolean result for legitimate failures is not enough. Likely a result object with some details is necessary.

There’s a target API we’re aiming for regarding verifications, so perhaps my answer makes more sense in context:

• verify*() methods should accept options for verification
• the options can be used to override some verification policies that are otherwise enabled by default (timestamps, credentialStatus, issuer DID document, schemas, holder binding, etc)
• The result of verification methods is an object with a verified boolean property for the overall result and detail properties for all the policies.
• Errors should be thrown only in exceptional situations, where the verification could not be completed (for example, because of a DID resolver error) or is inconclusive (for example, when the agent doesn’t support a particular policy required by the credential)
• Legitimate errors should be returned as details in the result object, and for simplicity, the verification should stop at the first policy with an error

There are legitimate reasons to be able to override policies. For example, “was the credential valid at a particular timestamp?”, “does the credential verify against this older version of the DID document?”, “is the credential valid but revoked?”, “is the signature valid regardless of schema?”. Overrides should not necessarily be encouraged, but they should still be possible.

[lleifermann]

@mirceanis Love the approach of this.

It very much reflects what we already tried to deal with on an HTTP Layer. See “Request Parameters” here -> https://open-credentialing-initiative.github.io/api-specifications/latest/index.html#/VerifiablePresentation/postVerfiablePresentationGeneration

I think these Params we have in place there are pretty much what you imagine to be a ‘verification option’.

In case of failed business cases we return a structure like this:

{
  "success": false,
  "errors": [
    "Generation of Verifiable Presentation failed because Credential has been revoked"
  ],
  "errorCodes": [
    "vc_revoked",
    "vc_proof_invalid"
  ]
}

I think this is pretty much 1:1 the same concept, just applied to another layer. From Client HTTP communication to Javascript/Typescript error handling and datastructures.

Really looking forward to the merge request @daniyal-khalil !