Credentials verification response needs additional work

[brownoxford]

Right now the documented response from a credentials verification check specifies that there can be three string arrays (checks, warnings, and errors).

In order to confidently write interop tests that include VC verification, we need to more details about what these string arrays will contain. See #169 for some of the current testing being done.

[OR13]

I added a boolean... but we still need to discuss less terrible solutions

[OR13]

We discussed on the call, @BenjaminMoe @nissimsan to propose a path forward, @brownoxford to recommend an approach.

blocked by lack of proposed solution.

[nissimsan]

@BenjaminMoe, let's discuss this tomorrow

[nissimsan]

@BenjaminMoe and I just talked this over.

First, we inherited the checks, warnings and errors arrays from VC-API. We propose that we get rid of this for the following reasons:

• These are poorly defined in VC-API, it's literally just an example, no schema. It just doesn't seem mature, and we probably overestimated its authority.
• It's been sitting stale for about a year now.
• None of the companies here seem to actually have implemented it.
• We have a better proposal!

Rather, what we propose for this response is two elements:

First, the "verified": true which we have already introduced.

Second, an array of verifications, which lists what went into the verification.

{
    "verified": true,
    "verifications": [
        {
            "status": "good",
            "title": "Activation",
            "description": "This credential activated 2 weeks ago"
        },
        {
            "status": "good",
            "title": "Signature",
            "description": "did:key:ni5kvh48ZRcVN2gfs6cteK8M1JzJdcwcYJak5R7VkhXeqsHn#z6Mkvh48ZRcVN2gfs6cteK8M1JzJdcwcYJak5R7VkhXeqsHn"
        }
    ]
}

Each verification would have: status (a "good"/"bad" enum), the title of the check (Proof, Activation, Expired, Revocation enum), and a free text description string.

[brownoxford]

Discussed on call. This is ready for PR, and suggested to bring this upstream to vc-api group.

[mkhraisha]

@msporny how do you feel about raising this issue/suggestion to the broader VC-API group

[msporny]

@msporny how do you feel about raising this issue/suggestion to the broader VC-API group

Yep, +1 to that... we touched on this in the VC API group 3 weeks ago: https://github.com/w3c-ccg/vc-api/issues/292#issuecomment-1162360310

We got to these concrete next steps:

PR needed: Define steps for verification at Verifier Service using normative language -- Check to make sure the structure of the VC is valid, check credentialSchema (if applicable), the verification method has not been revoked, check the credentialStatus has not been revoked

PR needed: Create an issue marker to note that checking whether current time is between issuance date and expiration date is still up for debate wrt. whether that is a check that's done during verification or during validation.

PR needed: Add options.eventLog (optional value), not mandatory, that provides the checks performed. By default that's turned off on successful verification. However, the eventLog is provided on failed verification.