Verifying and Validating issued VC's

[PatStLouis]

TLDR; how can the vc-api distinct generic verification from verifier specific validations operations on a VC?

A quick glance at the term verify could imply that there is a True of False verified status as an outcome but once you take into account other business rules this is not always the case. To address this it was discussed that there are 2 types of operation a verifier might conduct on a VC: Verification and Validation

Can we agree that the generic action of Verifying a VC would include:

• Verifying the data model
• Verifying the data integrity proof

Validating a VC can refer to any validation that is required based on an implementation's business logic layer. Such validations could include:

• Checking the status of the credential
• Checking the issuance/expiration dates
• Checking if the issuer is in a known trust registry
• Expecting a specific issuer did method
• Expecting a specific crypto suite (ie NIST compliant cryptography)
• Requiring specific VC components (credentialStatus, evidence, renderMethod, etc...)
• Other internal system checks

It would be great to address this in the VC-API. This should be tackled along the task of clarifying what the response from the /credentials/verify endpoint is. The 2 following approaches could be defined:

Option 1: Include both operations on the /credentials/verify endpoint:
The verification endpoint of most implementers already check the status/expiration date of VC they verify. I would suggest to keep this pattern but make the distinction more explicit in the response body:

{
    "verified": Bool, # limited to proof verification
    "valid": Bool, # True if all verifier specific validations are met
    "checks": [], # array of checks conducted as strings, MUST include "proof" + other verifier specific validations (expiration, revocation-status, known-issuer, etc...) would we want to define some of these?
    "errors": [], # String details of verification/validation errors
    "document" : {} # if `returnCredential` was set in the options, returns the VC
}

Option 2: Define a new /credentials/validate endpoint where verifier specific logic is isolated. This means the /credentials/verify endpoint would no longer care about expirationDate/credentialStatus

Let's scope this issue to credentials and address presentations in another issue if there's a need for it.

Please correct me on any assumptions made here, I'm only listing these as a starting point for discussions.

[PatStLouis]

Adding this excerpt from the verifier service. We should clarify what is to be part of the coordinator's role vs the service

The Verifier service takes requests to verify Verifiable Credentials and Verifiable Presentations and returns the result of checking their proofs and status (if present). The service only checks the authenticity and timeliness of the VC; leaving the Verifier Coordinator to finish Applying any business rules needed.

Defining which checks are part of Verifying vs Validating and which component/endpoint should conduct these checks (Service vs Coordinator) would be a good first step.

[TallTed]

One significant distinction between "verification" and "validation" is that "verification" is expected to be automatable and generically specifiable, and to involve crypto operations at various points.

"Validation" might be automatable, but cannot be generically specified, since it is based on the validator's business rules. "Validation" may involve crypto operations, in order to get the properties and/or values which are relevant to the validator's business rules.

The verb in all of the "Checking", "Expecting", and "Requiring" bullets should become "Testing", and include "against the validator's acceptable values". Whether something is "expected" or "required" or "checked" is part of the validator's business rules.

[PatStLouis]

Where would testing the validity date / status sit? While they are automatable and specified, a verifier might still have specific business rules around these tests. I might specifically look for a BitstringStatusList for revocation purpose and disregard other statuses. Maybe I'm only interested if a holder was previously issued a credential and not care if it's expired or not. Would we still agree to test status and expiration through a validation process step and keep verification to proof data model and context processing?

Taking the univerifier as an example, the verification includes proof parse issuance-date and expiry-date. An expired credential would be returned as un-verified. Would it be fair to change this behavior to consider issuance-date and expiry-date not having an effect on the verification of the credential but instead having an effect on the validity of the credential based on what the verifier wants to check for?

The same way we expect issuer services to be pre-configured with specific issuance options, a verifier would be configured with specific verification options (trust-registries, statuses to test/expect, specific VC features, etc...)

[msporny]

The group discussed this on the 2024-06-18 telecon:

@PatStLouis noted that verification should be around integrity of data and data model. Validation is about credentialStatus and other "business rules". Perhaps there are two endpoints there. Do we want to have another endpoint to test status and validation. @wes-smith noted that it's not clear how we define such an endpoint, for arbitrary business rules one could do validation. @msporny noted that it's not clear if this is a natural part of workflows, or if it's another endpoint, but thinks that its the former. @PatStLouis noted that the following things should result in errors for the verify endpoint: cryptographic signature failure, invalid data model and everything else should result in warnings (credential revoked, credential validity period expired or not yet valid, hash for linked resource is not correct, trust registry does not contain DIDs used to sign VC, and any other business rule, etc.)

A PR should be raised to note which errors verification should return, and note that everything else is a warning about validation.

[msporny]

The group discussed this on the 2024-08-13 telecon:

@PatStLouis noted that we have a /credentials/verify endpoint, which is used to verify credentials. Depending on what needs to be verified, status checking might happen, proof sets, multiple credential states, data model testing, each spec has some sort of validation algorithm section and an error processing section. Processing error, verifying the proof, what steps should happen, some define an object that should be returned about status validation. The VC API has a verify endpoint and a response, but we need to decide how much the response should match what's in the specs. The VC API is what we use to verify implementations of the VCDM v2 specification, and some verification is required. In order to test verification, they need to be exposed somewhere, verification endpoint can do that.

Verification is: What is the result of a particular check?
Validation is: Does your application accept the results?

Summary:

• Keep warnings, they're useful.
• Change "Status errors" to "status warnings", because that is more aligned with what they are.