First pass at updating validation language

[jandrieu]

This is an attempt to revisit validation vs verification #1232

---

Preview | Diff

[andresuribe87]

This is awesome, thanks! Small comment on links.

[decentralgabe]

great changes - approving noting @andresuribe87 and my comments

[iherman]

The issue was discussed in a meeting on 2023-10-11

• no resolutions were taken

View the transcript

1.8. First pass at updating validation language (pr vc-data-model#1297)

See github pull request vc-data-model#1297.

Brent Zundel: Joe has a response to an open issue.
… This updates the language in the spec around validation.
… There has been conversation, suggested changes that aren't in yet.
… There's at least one person that has approved it, we perhaps need more review.

Dave Longley: I haven't had enough time to look at this one, initial scan seems to add normative requirements around statements that are not testable... Verifiers must validate claims, that's usually done via business rules... validate using included business rules... we'll need to adjust that language in some way... not something an implementation can do... you might need to use your own business rules.
… Appreciate the effort to get clarity on verification vs. validation.

Manu Sporny: The only concerning bits of the PR are around normative statements around validation. I know Jeffrey Yaskin wanted us to specify verification algorithms, but validation is a bridge too far.
… There are multiple statements in this PR that say things like "verifiers MUST validate claims in VCs" which, again, is not testable. We don't want to get into validation rules.

Brent Zundel: I agree with that. I wanted to ask if the normative text here might be ... one of the suggestions made was that we more clearly define conformance rules. We could say "a conformant consumer of a VC... ought to do", whether and how that language would be normative around that is a another discussion.
… Perhaps putting this into conformant producers and consumers of the document is a step we could take. "Here's this data model and if you want to do something with it, here are some rules around that". It might be helpful if we went there.

Manu Sporny: One approach we could take there is the approach we took in the DID spec for DID method spec authors. We had normative statements around what DID specs must do -- I think Jeffrey Yaskin's review also covered that there are conformance classes in the spec that we don't define like conforming issuer/verifier.

Brent Zundel: +1 that's what I was getting at.

Manu Sporny: I think that's what you were getting at Brent, so we could have sections in the spec about what a conforming verifier must or should do and hand wave over that and say -- while those statements are normative, we're just saying what's expected from the conformance class, now how to do it but that one must do it.
… That might allow us to write normative statements and that we don't have entries for that in the test suite because it's general guidance.

Dave Longley: it's "business rules", not something a generic implementation would do.

Manu Sporny: Saying it out loud sounds problematic ... that's somewhere to try and go though.

Brent Zundel: For this PR advice would be to get rid of normative language, recognizing that moving forward with conformance on issuer/verifier roles we might need some "more normative" language and that might not be testable, but separate PR for that.

Manu Sporny: +1 to approach brentz suggested.

[brentzundel]

@msporny this PR still cannot be rebased and merged, and it is unclear to me what the scope of work is to accomplish that.
It could be squashed and merged. I understand that in general our preference is to rebase first, but in this case I think we should squash and merge so that we can continue moving forward.

(Edit: I just re-reviewed this PR and see that now there are a number of "changes" that seem to be pulled in from other PRs. I wonder if a new clean PR with only the text changes ultimately agreed to here would be the simpler route forward.)

[msporny]

@msporny this PR still cannot be rebased and merged, and it is unclear to me what the scope of work is to accomplish that. It could be squashed and merged. I understand that in general our preference is to rebase first, but in this case I think we should squash and merge so that we can continue moving forward.

Something has gone horribly wrong with the rebase/update of this PR. I'll look into what it might take to fix it. A squash merge might be all we can do at this point.

(Edit: I just re-reviewed this PR and see that now there are a number of "changes" that seem to be pulled in from other PRs. I wonder if a new clean PR with only the text changes ultimately agreed to here would be the simpler route forward.)

Yes, looks like Joe's main branch wasn't updated when he did an update/rebase, which caused all sorts of havoc in this branch... Joe updating his main branch and then rebasing this branch on top of the new main might fix the issue. I can try to do this manually when I get around to my next edit cycle.

In any case, I'll endeavor to get this text into the spec as cleanly as possible (unless @jandrieu beats me to the task).

[iherman]

@msporny , the git(hub) wizzard :-)

[jandrieu]

FWIW, I'll try to get to that this weekend.

Some people are emotionally scarred from bad experiences in their youth. Rebase is like that for me.

[msporny]

Merged via rebased PR #1334, closing.

[msporny]

Some people are emotionally scarred from bad experiences in their youth. Rebase is like that for me.

Well, that rebase was exceedingly painful. It took an hour to re-align everything. I don't know what happened in this PR, but let's please never do that again. :)

@jandrieu, you will want to check PR #1334 and make sure I didn't miss anything (I almost certainly did due to all the merge conflicts I had to resolve). If I did miss something, please raise a new PR to make the adjustments.

[TallTed]

all the merge conflicts

For future reference, I've found that PRs with major merge conflicts are far more easily addressed in BBEdit than just using GitHub's tools. There are some manual steps, because you have to create 2 documents in BBEdit, one containing the "new" text and the other containing the "old", by manually editing all the <<<<<< and >>>>>> sections — but once that's done, it can show you character-level differences which you can apply in either direction, each with a single click. I work this way until the two documents are identical, and the whole thing gets pasted into GitHub atop the conflict display.

This has saved me major time on documents of 10,000+ lines with varyingly huge length, that couldn't have been resolved on GitHub alone without days of work, if ever. It's only available for macOS, but there may be some similar tools out there for Windows or Linux.