search

w3c-ccg / vc-issuer-http-api

A specification for an HTTP API used to issue Verifiable Credentials.
https://w3c-ccg.github.io/vc-http-api/
Other
7 stars 5 forks source link

We need to define "verify" #14

Closed dhh1128 closed 4 years ago

dhh1128 commented 4 years ago

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. 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?

jchartrand commented 4 years ago

Similar to what I asked in #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.

dhh1128 commented 4 years ago

I need to move this to the verifier API; I mistakenly logged it against the issuer API instead. I will copy my original comment and @jchartrand 's follow-up over to a new issue in the right place.

dhh1128 commented 4 years ago

Superseded by https://github.com/w3c-ccg/vc-verifier-http-api/issues/6. Closing here.