Generalized Verification API in Veramo Core

[rado0x54]

As an Integrator of Veramo I would like to be able to use a single generalized Verification API that automatically verifies a various set of input data according to a given policy input.

Acceptance Criteria:

• There should be a single Verification API within Veramo core (Proposal: agent.verify({ payload: {...}, policy: {...} }))
• The fist step of the verification API is the identification of the payload format and determines what dynamic module is able to verify the given Payload.
• The generalized verification API allows for the registration of Modules to support new payloads.
• In the initial Implementation VC-JWT and VC-JSON-LD Credentials are supported with respective VC-JWT and VC-JSON-LD Verification Modules.
• Furthermore it should be able to Verify Verifiable Presentation Representations of JWT / JSON-LD Credentials
• The Verification API and the Verification Modules take an optional policy file that is able to influence the verification outcome.
• Each VC Verification Module is implemented independently, but generally it needs to verify the following. a) Schema / Data format. It needs to verify that the given payload matches the referenced Schema or Context b) Signature Verification. Verify that a Issuer Signature matches the given Credential and Issuer. c) Credential Status: Verify that the Credential Status of the VC is still valid:
• Policy files can model the following: a) Override certain assumption: Policy may allow to accept revoked credentials or self-signed Signatures. b) Tighten Validation conditions: Further restrict conditions of credential verification (e.g. similar to passing a PE), e.g. where certain values are expected. (Credential issued by specific issuer A) c) Trust Frameworks d) ... TBD
• Fixed Error Types for Verification Errors a) b) c) d)
• Policy Design, Module Integration and Payload Identification will be design as part of this ticket.

[rado0x54]

Figure out if there should be a Verifiable Presentation vs Verifiable Credential separation of interfaces. (in addition to a universal layer).

[italobb]

I would like to reinforce the importance of this issue hoping it can be prioritized. The usage of the DIF "well-known DID configuration" spec with the purpose of implementing discoverability and interoperability requires such support from Veramo.

[mirceanis]

It is easier to start with a more granular approach to verification instead of cramming everything into a thin top-level API. For this reason, I think it's best to start with different methods for verifying credentials and presentations. There is already a big gap between LD-proofs and JWT that indicates that we can go even more granular if necessary.

@rado0x54 you mentioned the requirement of adding verification Modules. This is a very important point and this is what I mean by starting from the lower level. All these specific verification modules would expose methods that can later be bundled up into more top-level interfaces once we have a better idea of how policies and their results would look like in reality.

---

Each VC Verification Module is implemented independently, but generally, it needs to verify the following. a) Schema / Data format. It needs to verify that the given payload matches the referenced Schema or Context b) Signature Verification. Verify that an Issuer Signature matches the given Credential and Issuer. c) Credential Status: Verify that the Credential Status of the VC is still valid:

I think maybe this approach is a bit too broad. I imagine much "smaller" checks, like: signature, issuance date, expiration date, challenge/domain, credential status, credential schema, etc... This allows different modules to implement different checks, and can later be extended with constraints or predicate checks.

A collection of checks forms a policy and then there can be a simple relationship between the policy requirement and a particular verification success or failure.

In some situations, it may be useful to give details as to why a credential or presentation fails verification, and having granular checks allows UIs to be built that can provide these details in app-specific ways.

[rado0x54]

Specific verification for LD-based credential and presentation was implemented in #273. Open for this ticket would be:

1. Generalization to JWT-based credentials
2. Generic CredentialStatus checks in the verification
3. Error Messaging and Handling.

[awoie]

@rado0x54 pls add tasks for this epic.