Need to define "verify"

[dhh1128]

(moved from w3c-ccg/vc-issuer-http-api#14)

Several things that a verifier does when evaluating a verifiable presentation are possibly intended by the verb "verify." We need to be crisp about which are in and out of scope for our API.

1. Checking the integrity of the artifact from a format and input validation perspective (correct MIME type, no magic byte sequence that makes the parsing engine blow up, the revealed "email" field actually looks like an email address, the revealed "name" field doesn't cause a buffer overrun, etc)
2. Checking digital signatures or ZK proofs in the presentation to confirm that they provide the evidence that they purport to provide.
3. Checking revocation status.
4. Checking whether a credential upon which the presentation is based was not expired for the timeframe the presentation targets.
5. Checking whether the presentation does, in fact, meet all of the criteria in the proof request. Note how this is different from item 2, in that what's proved could be less than what was requested. This includes checking whether the presentation is bound to the holder correctly (e.g., with biometrics).
6. Possibly, walking a data provenance chain in the credential and checking that it holds all the way back to the root of trust. (See Aries RFC 0104.)
7. Checking whether the presentation satisfies business requirements that were not expressible in a proof request. (For example, a verifier says they'll give some prize to the first 3 applicants who meet criteria X, Y, and Z. The proof request can express X, Y, and Z, but there's no way the verifier can demand that the holder prove they're one of the first 3 to apply. Only the verifier can test that.)

How many of these do we expect our verification API to support? And how do we distinguish between them when reporting errors?

[dhh1128]

(comment from @jchartrand, copied from w3c-ccg/vc-issuer-http-api#14 (comment))

Similar to what I asked in https://github.com/w3c-ccg/vc-issuer-http-api/issues/15 about whether 'services' might be a better abstraction than REST for issuance:

Could each of these verify steps be defined as discrete services (or 'microservices' or functions), each with their own API? Thereby allowing the steps to be combined together as appropriate for a given project, and varying the implementation of each function as appropriate for the project?

And again, like with issuance, I'm imagining something like a set of NPM packages, one per 'step' or function.

The packages could still make HTTP calls (e.g., to check revocation status), but that would be encapsulated within the package.

[msporny]

@dhh1128, I attempted address your question number 2 above "Checking digital signatures or ZK proofs in the presentation to confirm that they provide the evidence that they purport to provide." and create a pathway for addressing the rest of your questions via the following PR: w3c-ccg/vc-verifier-http-api#7

The PR basically takes in a VC (and eventually a VP) and runs a series of checks on it that are identified by strings. Results are a 200 OK if all checks passed, or a 400 error and an elaboration on which checks failed and for what reason.

I didn't try to answer all of the questions in the PR because it would be too much to get agreement on in a single PR. Would appreciate a review along with anyone else that wants to do one.

[OR13]

We also need to include support for:

How should we expose information about "revocation list" or "expiration" verification details failing in the verifier api?

[David-Chadwick]

5,6 and 7 are validation rather than verification and therefore should be out of scope

[peacekeeper]

We discussed this on the 05 Oct 2021 VC API Work Item call and agreed that verification is in scope. But we felt that validation of additional business logic (e.g. evaluating if a VP matches a certain request) should happen outside of the API.

Also see several other issues linked to this one.

It seems a PR should be created that documents this clearly in the API.

[dhh1128]

I agree with @David-Chadwick 's summary and with @peacekeeper 's call for a PR.

[msporny]

It seems a PR should be created that documents this clearly in the API.

It looks like a PR has yet to be raised to address this issue. We need to assign someone to write that PR.

[OR13]

I don't think we should define "verify" I think we should point to the VCDM defintion.

reopen if you disagree, and intend to open a PR with a proposal.

[msporny]

I don't think we should define "verify" I think we should point to the VCDM defintion.

I think you mean "we shouldn't define 'validate'", right? Because we define verify (checking items 2 and 3 from @dhh1128 list, but not getting into the other items because they constitute a certain sort of business logic). The expectation is that that sort of logic might be back-end configurable in the exchanges APIs, but we're not exposing any of that -- config or execution -- in the VC API).