Correct layering violations related to the proof property

[selfissued]

Remove uses of proof where a specific securing mechanism is not being used or described. Where proof is being used for Data Integrity, be explicit that that is the case.

This will resolve most of #1377.

cc: @jyasskin

---

Preview | Diff

[msporny]

This PR removes the proof property as an extension point, which we don't have consensus to do. It also makes a number of changes that are already made in other PRs, such as removing proof from a few examples. In many cases, it edits text that is in the process of being removed in other PRs.

I suggest waiting for the other PRs to settle and then seeing what is left. Some of the text in this PR is ok, but the removal of proof entirely as an extension point is the biggest issue.

[selfissued]

@msporny can you propose specific wording changes to the PR to address your concern? I'm OK leaving proof as an extension point provided that we leave it up to specifications using it to define how it is used.

[iherman]

The issue was discussed in a meeting on 2023-12-19

• no resolutions were taken

View the transcript

2.1. Correct layering violations related to the proof property (pr vc-data-model#1397)

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

Brent Zundel: Mike, you opened this one about an hour ago, I don't imagine people have had time to review.

Michael Jones: Thank you.
… I was assigned an issue about working on correcting layering violations. I finally allocated a couple days time to work on VCDM. Yay -- to try and help us finish.
… Most of the layering violations that were present that I found had to do with unlabeled uses of the proof property. Places where proof was present but it wasn't said that it was specific to certain securing mechanisms. I did some of this a while ago to sync with vc-jose-cose.
… This PR tries to be even handed around where proof is used and we say it's an example of using Data Integrity and where it wasn't needed I just removed it.
… There is another PR to go along with this in Data Integrity where I wanted to be really careful where if I removed anything in the VCDM PR that needed to be said in DI that I wanted to be sure that DI said it.
… The good news is that I read every line of my PR that was being removed and looked at DI and made sure that in almost all cases it was already said in DI. Only one sentence wasn't there. I am trying to be even-handed and positive and the point is to be agnostic to the securing mechanisms.
… I hope that this helps close the issue about having an even-handed verification method.
… Unless there are questions from people who have actually read it, I suggest we move on. I just wanted to flag to say we want people to read it because it gets us to closer to CR.

Brent Zundel: If anyone has read it please jump on the queue.

Manu Sporny: I was able to read it before the call. Some of the changes in the text being made has already been removed in other PRs.
… That includes removing proof from some examples that has already been done in other PRs. That includes removing conformance statements around proof that are also gone. This PR would be removing things that are already taken care of elsewhere.
… The one problem is with removing proof as an extension point. There's a mismatch in understanding there I think. The proof property is not meant to be DI-only, but an extension point to be used by other securing mechanisms, some that may not be DI.
… That's my concern with the PR -- where it removes the extension point.
… I don't think that was the intention of proof being an extension point. Otherwise, the PR is removing things that other PRs remove and that's fine. So I'm only worried about removing proof as an extension point.

Michael Jones: Glad to hear that other PRs are already handling much of this.
… We can all declare victory there.
… With respect to the extension point point ... I tried to be really judicious about whether there are examples using proof ... where there are examples I said this is an example that could be secured using DI.
… Quoting myself, something to the effect "proof can be included if specified for use by a securing mechanism." So any securing mechanism can be used, but it's not something you'd put in if the securing mechanism doesn't call it out. So I don't see it as needing to be a general extension point.
… Any securing mechanism can define an extension point and one of those can be proof.
… We can talk about that in the PR if you want.

Brent Zundel: That's my recommendation, continue the conversation in the PR. It's been live for an hour, so get your reviews in.

Michael Jones: Live for an hour, but two days of work, had to read lots of text.

Brent Zundel: Thank you, Mike.

[msporny]

@msporny can you propose specific wording changes to the PR to address your concern? I'm OK leaving proof as an extension point provided that we leave it up to specifications using it to define how it is used.

Yes, most of the significant concrete change suggestions are in these PRs:

• PR Clarify that "proof" is an extension point #1389
• PR Clarify how issuer validation occurs. #1393
• PR Use new Securing Mechanism Verify Proof interface #1394

If/when those PRs land, the other concrete changes I'd suggest to this PR would be in text that is deleted (and therefore, there is no sense in making those changes since the text will disappear if the PRs above are merged).

Most of the changes fall into those two categories. We'll have to see what the delta is if/if not the PRs above land and go from there.

[iherman]

The issue was discussed in a meeting on 2024-01-03

• no resolutions were taken

View the transcript

1.1. Correct layering violations related to the proof property (pr vc-data-model#1397)

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

Brent Zundel: looking at 1397 (#1397) - has been superseded by other PRs? is that correct.

Manu Sporny: next step is for Mike to look at the latest spec and see what the delta is. probably a minimal change set at this point.

[selfissued]

I plan to resolve merge conflicts after PR #1403 has been merged, and ideally, also #1404.

[selfissued]

All, please re-review. This PR now does less than it used to because some of the preceding PRs already accomplished some of the goals of this PR.

[iherman]

Why removing this?

The preceding paragraph on enveloping proof uses the same terminology to 'recommend' jose-cose. This paragraph does the same for DI. Either both RECOMMENDED statements are removed, or none of them. Personally, I prefer keeping it as is: after all, we are 'recommending' the two proof mechanisms that this WG standardizes, which is perfectly fine, and it certainly does not exclude third parties coming up with their own.

[msporny]

Agreed. Do not remove this, the WG is explicitly recommending at least the securing mechanisms that it is publishing as standards.

[brentzundel]

both paragraphs should be consistent

[iherman]

I do not think it is necessary for this example. Example 18 does not use any proof mechanisms, so the reference to DI looks irrelevant.

[msporny]

Just a few blocking requests, after these are fixed (and the change suggestions are integrated), we can merge:

• Do not remove the recommendation of using the securing mechanisms the WG is creating.
• Do not remove text related to DI and replace it with text related to JWT -- either talk about both mechanisms specifically, or securing mechanisms generally, or be silent.
• Keep the mentions that proof or securing data is placed in a separate graph; it's important to be able to separate the securing mechanism from the data being secured.

The PR still has merge conflicts, so we'll have to make sure those are fixed before we can merge as well.

[msporny]

Agreed. Do not remove this, the WG is explicitly recommending at least the securing mechanisms that it is publishing as standards.

[msporny]

We will want to just reword this to refer to the "Securing Mechanisms" section. This is not blocking feedback, and it's editorial, but while we're in here we might as well change this/update it to point to a better place.

[msporny]

-1 to removing this text AND adding the JWT text. Either remove all of it, or add all of it.

[msporny]

@iherman this is removing all notions that proof is a separate graph, which doesn't seem like a good idea. You added this text, thoughts?

[iherman]

Good point but, with this new setup, the fact that a proof creates a new named graph must be added somewhere to the DI spec, and it is ok not to have it there.

At this point we probably should raise a new issue in the DI repo to remind us that this MUST be done, and leave this change as is.

[selfissued]

I agree with @iherman that this information belongs in DI - not VCDM.

[msporny]

Normative, multiple reviews, changes requested and made, no objections, merging.

[TallTed]

The history of this PR suggests that all my requested changes were applied, but they were NEITHER ACCURATELY NOR COMPLETELY applied, apparently because the "commit" buttons provided by GitHub were not used on all (if any) suggestions.

Manual application of change requests is HORRIBLY error prone, and it is impossible to know whether requested changes were rejected intentionally (which should have led to discussion and agreed resolution) or accidentally — which means manual review of each-and-every change request and subsequent commit must now be performed.

I noticed this problem when skimming the "files changed" after the PR was merged. The word "complementary" was deleted, where it should have moved from one line to the next. The original sentence read —

The `evidence` [=property=] provides different and complementary
information to the `proof` [=property=].

The remaining sentence is nonsensical —

The `evidence` [=property=] provides information that is different from and
information to the securing mechanism utilized.

It should now read —

The `evidence` [=property=] provides information that is different from and
complementary to that provided by the securing mechanism in use.

I am VERY unhappy.

[TallTed]

Perhaps GitHub is providing the stress here... The files changed shows the broken sentence above, while the main branch shows the correct sentence.

I don't know of a good way to review this, that will accurately show the requested changes and their disposition, other than comparing the PR to the Main branch in side-by-side browser tabs...