Proof of control over DID during Verifiable Presentation

[simibac]

Let's assume we have two VCs. VC1:

{
    credential: {
        credentialSubject: {
            id: DID1
        }
    ...
}

and VC2:

{
    credential: {
        credentialSubject: {
            id: DID2
        }
    ...
}

Now I want to create a VP that discloses VC1 and VC2. When creating a VP, we create a proof JWT. By using DID1 to sign and generate the proof, I also prove that I am in control of DID1.

{
  "presentation": {
    holder: DID1,
    verifiableCredential: [
      {
        credentialSubject: {
          id: DID1
        },
        ...
      },
      {
        credentialSubject: {
          id: DID2
        },
        ...
      }
    ]
  }
}

But I do not necessarily control DID2 as well. So how does Veramo validate, if I am in control of the DIDs that appear in all of the VCs?

Furthermore, I still don't understand how Veramo's VP validation works without a challenge\response workflow. In this answer, it says that the VP incorporates the SDR JWT. Could you please post such an example of the SDR and the VP?

[mirceanis]

Excellent questions.
The answer is rather simple and probably disappointing.
At present, veramo doesn't validate that all the VCs in a presentation are about the same subject (the holder).
This is half by design and half not-implemented-yet.
Some form of holder binding validation is planned as a part of the bigger vc/vp verification story (look for #375), and the "by-design" part is because not all protocols will require holder binding.

As for the other answer, I think I misrepresented the current implementation of selective-disclosure.
It is inspired by the uPort selective disclosure but doesn't have all the features from it.
Frankly, the current implementation is more of a proof of concept than a reference implementation.
I'll try to provide a more detailed answer there.

[simibac]

Thank you for the answer. I am wondering though what use case would not require holder binding?

[mirceanis]

I can think of a few.

For one, a VC may have a subject that is not a DID.

Or, imagine a holder service that presents credentials that are meant to be public, but about other entities (like a phone book).

Or, think of a presentation that contains some sort of linkage credential. Did1 proves that they represent did2 by a linkage VC where did1 is the subject. And then did1 presents this VC along with others that are about did2. So this would be a VP with did1 as the holder but the VCs are about different subjects.

I hope this helps