-
Notifications
You must be signed in to change notification settings - Fork 47
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Need to define "verify" #59
Comments
(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. |
@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. |
We also need to include support for: How should we expose information about "revocation list" or "expiration" verification details failing in the verifier api? |
5,6 and 7 are validation rather than verification and therefore should be out of scope |
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. |
I agree with @David-Chadwick 's summary and with @peacekeeper 's call for a PR. |
It looks like a PR has yet to be raised to address this issue. We need to assign someone to write that PR. |
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. |
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). |
(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.
How many of these do we expect our verification API to support? And how do we distinguish between them when reporting errors?
The text was updated successfully, but these errors were encountered: