Improve Verification Algorithms section

[msporny]

This issue is being raised to generally track improvements that we might make related to the new Algorithms section in the VCDM specification.

Namely, the interface between the Verification algorithm in the specification and the Securing Mechanisms isn't as clean as it could be and we might try to define the exact interface that should be used for extractDocument and verifyProof in the securing specifications such that all securing specifications need to define these functions and point to them from the VC Specifications Directory.

This issue might not result in any PRs and is intended to be a place where we can continue some discussions that were started in PR #1338. /cc @jyasskin

[OR13]

This needs to be solved in each securing mechanism.

specifically, proof handling in data integrity, header / alg processing needs to be handled in vc-jose-cose.

I objected to #1338 because the core data model should not be in the business of defining securing related verification procedures.... and I have continued to object to the presence of proof in the core data model, for the same reason.

[selfissued]

I agree with Orie that defining how to verify that the content is secured and how to extract the secured content belongs in the securing specifications and not in the core data model.

[iherman]

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

• no resolutions were taken

View the transcript

1.3. Improve Verification Algorithms section (issue vc-data-model#1362)

See github issue vc-data-model#1362.

Brent Zundel: There is a PR in progress that adds a verification algorithm to the spec.
… It seems to be progressing well.

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

Manu Sporny: There was at least one thing - it's not clear if we're going to be able to make the PR.
… We need WG consensus.
… We need to define an interface in the securing mechanism.
… Jeffrey wants us to do that.
… We need a uniform interface.
… Currently we provide instructions for DI and jose-cose.
… about the extraction and verification functions.

Michael Jones: as pointed out by Brent on the Editors call yesterday, we're explicitly not chartered to to APIs.
… what's being proposed here is an API, so therefore out of scope. It's fine to define normative language in the two securing specs.
… but providing an API to do it goes against charter.

Manu Sporny: This is not an API: #1338 (comment).

Manu Sporny: We do define algorithms.
… That's in scope.

Michael Jones: Then call them algorithms - not a uniform interface.

Manu Sporny: Done.

Brent Zundel: The concern I have is that what we have in #1338 is in response to comments from a W3C member saying that if this isn't addressed, they will formally object.
… On the other hand, we have charter language prohibiting creating APIs.
… From my perspective, the safe route is to figure out an algorithm to address this.

Manu Sporny: Jeffrey has approved the PR.
… It is definitely a grey area.
… If there is concern about somebody objecting to the charter, we have a strong defense.
… This can't work without algorithms.
… We have a path to defend against formal objections.

Brent Zundel: We will have a more thorough conversation about #1338 tomorrow.

Orie Steele: lets make sure the algorithm does not contradict any of our terminology or definitions, particularly the "extract" vs "credential" definitions.

Manu Sporny: The algorithm is meant to defer to the securing specs for all important implementation details.

Manu Sporny: agree with Orie that we don't want those algorithms to contradict any terminology/definitions in the securing mechanism specifications.

Dave Longley: and agree it's important that the algorithm not impede things like SD-JWT and ECDSA-SD.

Brent Zundel: If we get agreement on #1338 then #1362 can be closed.

[msporny]

This issue is now overtaken by #1377. Closing.