Revisit validation vs verification

[OR13]

originally raised by @jandrieu regarding #1199

We have "verification" like stuff in the "validation" section.

We need to plan how to address this in relation to all the sub sections, not just the "holder" and "issuer".

@jandrieu can you leave a comment outlined how you would like to see the whole section address this issue more consistently?

[decentralgabe]

FWIW I wrote a bit about this recently. Would be interested to hear whether the group agrees with my language:

Both terms get thrown around and it can be confusing to determine what each means! Usually, when talking about digital signatures we talk about signing and verifying so verification is a necessary part it making sure a given digital signature is valid. Validation can be a more thorough process, containing any of the aforementioned validation steps, of which verification is a crucial step. Verification can be used in another sense too, since the name of the technology is "Verifiable Credential." Can a credential be verified without it being valid? Maybe, if by verified you mean the signature checks out. Can it be valid without being verified? Probably not.

For the sake of simplicity let's say that a verifiable credential undergoes a verification process, within which, there are a number of validity checks. After passing all validity checks the credential is both valid and verified ✅.

[iherman]

The issue was discussed in a meeting on 2023-08-15

• no resolutions were taken

View the transcript

2.8. Revisit validation vs verification (issue vc-data-model#1232)

See github issue vc-data-model#1232.

Kristina Yasuda: on previous sd-jwt issue, yes, sd-jwt spec will register three new JWT claims _sd and _sd_alg and ....

Brent Zundel: assigned to manu and we will move forward. 1232 - revisit verification vs validation, assigned to Joe.

Joe Andrieu: only assigned 16m ago! not clear whether before/after CR, so let's go with before and maybe a draft PR.

[longpd]

Is the core issue here that verification is about the correct syntactical structure of a credential such that it can be determined to be well structured and securing methods applied to detect tampering? I have understood verification to mean the JSON-LD presented is conformant to the requirements imposed by the core VC data model.

Validation, on the other hand, is about business logic that is applied to the credential and in that sense is certainly required that the data model of the credential presented is conformant to the VC data model. But validation is about logical considerations such as whether the credential has been revoked by the issuer. There may be circumstances where there are other business rules that a relying party is concerned about and therefore a validation process that checks these is followed. The core question: is verification about conformance to syntax rules of the VC data model and validation about logical business rules that should be checked, aka validated?

[OR13]

Validation is the process of applying business rules or a policy to the result of a successful verification.

Validation always fails when verification fails.

Validation can succeed depending on the rules or policy, based on the attributes of a credential or presentation.

When an attribute or extension is not understood, it is assumed to be acceptable, in other words, if you don't check the status when its present, validation "passes" without doing the check... (fails open).

At least the following properties SHOULD be checked by rules or a policy and if present and "not acceptable to the verifier", validation SHOULD fail in order to mitigate the risk of failing open:

0. issuer / holder
1. validFrom
2. validUntil
3. credentialStatus
4. credentialSchema
5. proof & proofPurpose

The following extensions are reserved, but cannot be validated due to lack of definition:

0. confidenceMethod + ConfidenceMethod
1. renderMethod + RenderMethod
2. termsOfUse + TermsOfUse
3. evidence + Evidence
4. refreshService + RefreshService

See also this visual representation of this fact, based on comment here: #1263 (comment)

[TallTed]

Validation always fails when verification fails.

Beware absolutes like the above which inappropriately dictates business logic.

Verification fails when a VC is expired, as with an expired driver's license, but it might still be considered valid for proof of age.

[iherman]

The issue was discussed in a meeting on 2023-08-30

• no resolutions were taken

View the transcript

4.6. Revisit validation vs verification (issue vc-data-model#1232)

See github issue vc-data-model#1232.

Brent Zundel: revisit verification and validation.

Joe Andrieu: I don't think there's been any forward movement.
… I do think it's on me to do a review on validation/verification... could come back and add them as comments. I think that's where we're at.

[jandrieu]

Consider a proposed PR to the requirements doc for some language on that side of the spec (more about requirements rather than how we meet those requirements) w3c/vc-use-cases#149

[Sakurann]

why pointing to RFC4949 and simply saying what I quoted below is not sufficient?

Rule 1: Use "validate" when referring to a process intended to establish the soundness or correctness of a construct (e.g., "certificate validation"). (See: validate.)
Rule 2: Use "verify" when referring to a process intended to test or prove the truth or accuracy of a fact or value (e.g., "authenticate"). (See: verify.)

[iherman]

The issue was discussed in a meeting on 2023-09-14

• no resolutions were taken

View the transcript

2.6. Revisit validation vs verification (issue vc-data-model#1232)

See github issue vc-data-model#1232.

Brent Zundel: Raised by Orie on behalf of Joe... what do you need to write a PR here?

Joe Andrieu: We have text in use cases document now, if people can look at the use case document, that would be helpful.
� PR 149 use cases has that document.

See github pull request vc-use-cases#149.

osamu-n: osamu-n has joined #VCWG.

Manu Sporny: (The group reads through PR 149...).

Joe Andrieu: +1 to Phila and DMV. Please comment and I'll work on it.

Brent Zundel: To summarize -- verification checks syntax and cryptography checks out, validation has to do with business logic, and that's how verification and validation are different from one another.
� If there was a PR in the core data model, that aligned with the use cases text, would that be appropriate to those in the WG?

Manu Sporny: The only thing that jumps out is the use of normative language in the use cases document.
� it's a bit confusing.

Joe Andrieu: is it normative language or not?

Manu Sporny: The core seems correct and is a clarification the VCDM would benefit from.

Brent Zundel: any other comments from folks?

Shigeya Suzuki: +1 on reference to DMV.

Brent Zundel: I hear concern about normative language, much broader concern about use cases document -- issue on use cases document would be a good way to track that.

Manu Sporny: I'd be fine w/ an issue to track that ^.

Brent Zundel: the normative language is bigger than just this PR. so a separate issue on the use cases document is probably the right place to go.
� With that, Joe, do you feel like issue 1232 -- do you feel confident moving forward with a PR at this point?

Joe Andrieu: Yes, seniment feels like this is the right direction. Would like to hear from others on the queue. Challenge with normative language is that this is requirements for the spec, that's why we use normative language.

Ted Thibodeau Jr.: We might want to use requirements language instead of normative statements.

Brent Zundel: PR within the next week?

Joe Andrieu: +1 manu I agree we should add that. A note on this PR or in a new issue would tag it for me to follow up on.

[David-Chadwick]

But validation is about logical considerations such as whether the credential has been revoked by the issuer.
I disagree with this statement. Revocation is a verification issue. If the VC has been revoked then it cannot be verified e.g. because the issuer's signing key has been stolen.
You should think of verification as being application independent and checking that the signature is sound, so that it can be carried out by an independent third party service, whereas validation is application dependent code and should reside in the RP.

[David-Chadwick]

Validation always fails when verification fails.
I disagree with this statement. A verifier(RP) may accept a VC that fails verification for many reasons e.g. it has expired, it has been suspended, it is not yet in its validity period e.g. it starts next month. The RP always decides which VCs are valid and which are not.

[David-Chadwick]

@Sakurann. I dont think that Rule 1 is sufficient for VCs because one RP may accept (validate) a VC that another RP does not. So the same VC cannot be both correct and incorrect (unless the process is not fixed and is validator dependent, in which case the process simply becomes "whatever I say is correct".

[msporny]

PR #1297 was raised to address this issue. PR #1297 has been merged via PR #1334, closing.