standardize verification processes for a variety of well understood use cases

[kdenhartog]

Right now we've established a strong data model with a good set of extensibility to meet the needs of a variety of use cases. With each of these use cases we encounter common patterns of verification of both the VC data model and VP data model, but none of these patterns have been standardized in a meaningful way to allow a developer who's utilizing the data model to pick up the libraries and easily utilize the data model in a safe way.

What I'd like to propose as a potential path forward is to standardize common verification patterns such as:

1. Verifying simple claims assertions
2. Verifying multiple credentials in a verifiable presentation that are linked to the same subject with the same holder
3. Verifying multiple credentials that are about the same subject but have different holders
4. Verifying multiple credentials that are about different subjects but from the same holder

While this does step into the realm of "building protocols" I think we can steer clear of this by focusing only on how to process a VC/VP data model that's been received while clearly leaving the method of which a VC/VP is transferred out of scope.

To put it simply, in Appendix A we say:

While this specification does not provide conformance criteria for the process of the validation of verifiable credentials or verifiable presentations, readers might be curious about how the information in this data model is expected to be utilized by verifiers during the process of validation.

Essentially what I'm aiming for is to provider further normative conformance criteria for some of these common validation patterns.

[iherman]

The issue was discussed in a meeting on 2021-12-08

• no resolutions were taken

View the transcript

1.5. standardize verification processes for a variety of well understood use cases (issue vc-wg-charter#30)

See github issue vc-wg-charter#30.

Brent Zundel: This is from Kyle Den Hartog. I don't think we've looked at this yet -- Kyle not on the call too early for his timezone..

Kevin Dean: This is going to be difficult. Verifying the content ... the business process can be radically different from one to the next. He is talking about common validation. Talking about driver's licenses and the like..

Manu Sporny: I agree with what Kevin just said. I am a bit confused because he jumps between verification and validation patterns. He says standardize verification processes but at the very bottom he says he'd like common validation patterns standardized. And verification and validation are not the same..
… Right now the spec has a list of things to do for verification like check the signature and credential status. I think we need to ask Kyle if he's talking about verification or business process validation the latter of which we can't do..

David Chadwick: I totally agree that we're only talking about verification and not about validation. This has come up in the presentation exchange group -- which is that one of the components is that you can check the policy before checking any proof. I am strongly for always checking a proof before checking any policy..

Manu Sporny: +1 to what DavidC just said -- check the signature first before doing any processing..

David Chadwick: Proof checking should be the number 1 to lower the attack surface..

[kdenhartog]

Just saw the notes on this and wanted to clarify this would be specifically about common verification patterns. I was not thinking about venturing into common business logic validation which I agree can differ widely based on the use cases. With that in mind, I want to further clarify what I mean here by verification. I do believe it's necessary to state the verification processing logic for more complex verification processes beyond how to verify a single VC that's been wrapped and signed with a VP.

[brentzundel]

would this reasonably fall within the scope of VC Data Integrity (#32)?

[kdenhartog]

would this reasonably fall within the scope of VC Data Integrity (#32)?

Yeah based on our discussion on todays meeting I think this is definitely covered by the multi proof sets of VC data integrity from LDPs draft spec and should be covered with no additional scope needing to be covered in the charter. I think this can be closed.

[iherman]

The issue was discussed in a meeting on 2021-12-15

• no resolutions were taken

View the transcript

1.3. standardize verification processes for a variety of well understood use cases (issue vc-wg-charter#30)

See github issue vc-wg-charter#30.

Kyle Den Hartog: Given the scope of the work, don't know if we want to take this on now. Ok with leaving it undefined, can advocate inside WG for it if we have time for it..
… Otherwise, ok to leave it out of scope and we can tackle it in time..

Brent Zundel: Do we have to be specific about this being in scope?.

Kyle Den Hartog: We probably walk ourselves into problems if we go to REC... we weren't being explicitly clear... multi-issuance and multi-proofs. Given that you can do multi-proofs in LDI, we could argue that it was a part of it at the out set, might make it unclear where we fell on that sort of stuff..
… Maybe when we list LDI, we specify multi proof sets?.
… When we were talking about LDP, we were looking at specific proof suites, Edwards and BBS+ for multiproof systems..

Manu Sporny: I'm trying to get a link.
… for the LDP spec which includes section 7 with multiple proofs.
… but I'm not sure this addresses what you were talking about.

Manu Sporny: https://w3c-ccg.github.io/ld-proofs/#multiple-proofs.

Kyle Den Hartog: yes, we did run into this problem, that's exactly what I was thinking about -- not clear, when writing suites, combine them into VP, how you prove that they've been bound to the same identity and both are presenting together vs. two independent subjects generating presentation..
… For example, mortgage, married couple signs independently, sign together on single document, you could do multi proofs, subjects different can sign same thing. Generic way to express those same proofs w/ multiple subjects not very clear at this point.

Dave Longley: input doc on ld proofs should give us the space we need to work on multiple proofs on a single document.

Manu Sporny: agree, we can always add examples..

David Chadwick: Just two points, one is the current text is that appendix A refers to validation.
… and this should say verification.
… and the second point that Kyle was saying is that it brings back if the IDs refers to the holders or the subject and I would hope that would come into this.
… since one way of resolving this is to rely on a proof of possession in all of these.
… Do people remember this discussion and how we had two separate views for this? I think that discussion would feed well into this.

Manu Sporny: Yeah to what kdenhartog and what has been said in chat I think we have space to make it clear that we can show how that's done.
… so I think we're in safe territory.
… with respect to what DavidC I vaguely remember the discussion but none of the details.
… maybe the multiproof stuff brings that to the fore.
… and in a fairly normative way.

Dave Longley: +1 multiproof in scope and talking about ID relationships and establishing proofs are in scope.

Kyle Den Hartog: In that case, I feel like it's justified and in scope based on what we know about LDI and LDP to be able to say there is no necessary updates to the charter in order to close out this issue. This will fall in naturally to talk about these sorts of use cases..