Do we need distinct use-cases for verification and validation?

[RieksJ]

I just read @jandrieu's post of Monday 16-8-2021, 32:16 CEST to the Credentials Community Group (I have no clue about a link to make it easier to reference), called "Diagrams for VC HTTP API work", in which he included the following diagram for the issuance of credentials:

What I find noteworthy is that the issuer role is no longer just issuing a credential in the earlier request-response manner, but (in step 2) it also seems to send a presentation-request like message to the holder app, resulting in a VP that is verified in steps 9-11.

It seems as if a new VC is minted based on the verification result. This is wrong - not because a VC should not be minted conditionally, but the condition it is to be based on should not be 'verification', but 'validation', which is not the same thing.

Verification is a test on the structure of data, whereas validation tests the validity of such data for a particular (set of) purpose(s), which also has to do with meaning. Specifically, data that fails particular verification tests can still be valid for some purpose. For example, a passport that has recently expired may still be valid to identify its bearer, e.g. to allow him to enter a building. The converse may also be true: data that satisfies timeliness tests, e.g. hasn't expired yet, may still not be valid for for specific purposes. For example, in order to apply for a Chinese (tourist) visa, the passport must not expire within 6 months of arrival in China.

Since verification is a test on the structure of data, I can see verification-technology being standardized. The presentations that are to be considered valid for the issuing of a certain credential (or for the provisioning of another product/service) depend on business rules, so validation-technology can only be standardized to the point where it can accept and work with policies that are created/maintained by the party that deploys such technology.

The question then is whether or not use-cases should be included in the document that clarify this, perhaps call for a more explicit validation role and associated technology.

[KDean-GS1]

Merging with #96. Please address all comments there.