veramo
veramo copied to clipboard
Added policies to verifyPresentation in credential-w3c module
What issue is this PR fixing
partially fixes #954
What is being changed
Adding the IVerifyPresentionResponse
interface in the credential-w3c module to be able to implement better error handling, the new interface allows the errors to be communicated through an Object containing fields, verified
, details
, errorCode
.
-
verified
defines the state of the verification process, whether it failed or is passed. -
details
contains details regarding the failure for the verification process. -
errorCode
can be used to pass machine readable errorCodes from the lower level modules.
Quality
Check all that apply:
- [X] I want these changes to be integrated
- [X] I successfully ran
yarn
,yarn build
,yarn test
,yarn test:browser
locally. - [X] I allow my PR to be updated by the reviewers (to speed up the review process).
- [X] I added unit tests.
- [ ] I added integration tests.
Details
Was unable to find specific verification tests in the action-handler.test.ts
in the credentials-w3c module so created another test suite like in credentialLD module for issue-verify-flow.
Codecov Report
Merging #990 (aeb379b) into next (7152a53) will decrease coverage by
0.19%
. The diff coverage is57.14%
.
@@ Coverage Diff @@
## next #990 +/- ##
==========================================
- Coverage 80.83% 80.63% -0.20%
==========================================
Files 116 118 +2
Lines 3981 4090 +109
Branches 867 896 +29
==========================================
+ Hits 3218 3298 +80
- Misses 760 789 +29
Partials 3 3
@mirceanis I was wondering whether you'd prefer if I create a IVerifyResponse
as a type in Veramo core which will have a general verified
and error
fields. This can be used generally in all Verification APIs in separate modules.
@mirceanis I was wondering whether you'd prefer if I create a
IVerifyResponse
as a type in Veramo core which will have a generalverified
anderror
fields. This can be used generally in all Verification APIs in separate modules.
Yes, that sounds like a good idea, although IVerifyResult
fits the action better, since these are not actually request/response pairs.
I think even if I proceed to create separate PRs for the credential-ld
and credential-eip712
modules. I would still need to refactor the verifyPresentationLD
to support the current PR because the else
clause responds with the LD verification. Which I believe is incompatible with the current IVerifyResult
Response.
If we align on the approach, then I think it would not take long to implement similar logic for all the verify*
methods.