Potential problem with Example 2

[iherman]

There may be a problem with Example 2, similar to the one reported in #217.

TL;DR: the block on VerifiableCredential may have to be exchanged to something like this:

        {[
         "@context": ["https://www.w3.org/ns/credentials/v2"], 
         "type": ["EnvelopedVerifiableCredential"], 
         "id": "data:application/vcld+json+sd-jwt;eyJhbGciOiJFUzM4NCIsImtpZ…" 
     }] 

The reason: the definition of the verifiableCredential property requires the value to be a VerifiableCredential or an EnvelopedVerifiableCredential. The question that comes up is whether a VerifiableCredential object without a securing mechanism (a.k.a. proof) is allowed within a verifiable presentation or not. The claim is that the answer is 'no' (@msporny, you should chime in on this), although, I must admit, this is not crystal clear in the VCDM spec, and it should, maybe, be made clearer.

If we agree that this is the case, then the question is how that would work in combination with JOSE: can an enveloping proof like JOSE be encapsulated in another JOSE payload? Because if the answer is no, then the only viable approach is to use the EnvelopedVerifiableCredential approach above. (Unless we would use DI for the securing of the credential, which would be a mix of two securing paradigms; probably a no-no.)

Another possibility is that we make it less stringent in the VCDM, and we do allow a credential in that position, i.e., without a securing mechanism.

Note also the related Figure 10 in the VCDM.

(I marked this as 'before CR' because it does raise some fundamental issues about JOSE-COSE/VCDM relationship.)

CC @decentralgabe @msporny @dlongley

[TallTed]

a mix of two securing paradigms; probably a no-no

This concerns me. To my mind, a Holder should be able to compose a Verifiable Presentation from Verifiable Credentials that use any mix of securing mechanisms.

If not, then a Holder must know from the start which securing mechanisms all of their Issuers will be using, for all time henceforth, and/or be able to request which mechanism is used to secure any given (or refreshed) VC, such that any given Verifier's request may be satisfied.

Failing that, the Holder must be able to provide multiple VPs simultaneously to a given Verifier — who must also be able to blend the contents during Verification/Validation.

(Of course, there's also the possible need to Selectively Disclose partial contents of multiple VCs in one VP...)

All of this probably leads to a new Issue, and, seeming normative, may need to be addressed before-CR (or for CR2 or later).

[iherman]

a mix of two securing paradigms; probably a no-no

This concerns me. To my mind, a Holder should be able to compose a Verifiable Presentation from Verifiable Credentials that use any mix of securing mechanisms.

If not, then a Holder must know from the start which securing mechanisms all of their Issuers will be using, for all time henceforth, and/or be able to request which mechanism is used to secure any given (or refreshed) VC, such that any given Verifier's request may be satisfied.

You are right, @TallTed. I guess my comment was aimed at whether using DI is the only mechanism to embed a credential into a presentation.

[decentralgabe]

Three thoughts:

1. You should be able to mix and match DI and JOSE/COSE credentials.
2. Credentials in VPs must be secured.
3. Data Integrity is not the only mechanism to embed a credential in a presentation, can use JOSE/COSE with the enveloped type.

[decentralgabe]

I will self-assign and add an example that shows a VP containing JOSE/COSE credentials, as well as updating the text to the above.