Re: Proof flavours in Verifiable Credentials

In theory, the material that's signed in a credential could be
double-signed instead of single-signed (once for each style). Indeed, I've
done some exploration of that idea, and would be interested in doing more.
However, there are subtle issues that make this harder than we'd like. For
example, revocation strategies are different between the two credential
types. We would also have to guarantee that the semantic content in the two
versions is identical; divergence could create some abuse scenarios. Note
that ZKP signatures, because they are intended to back proofs of
arbitrary sets of fields rather than always the credential as a whole, are
more granular than the other type. (I believe the mechanism Workday
described at the last IIW is an example that sits partway in between, where
it still discloses signatures, but builds a merkle tree of them so
individual fields or sets thereof can be attested. A Workday person on this
thread will know more.)

In the meantime, the Aries protocol has begun exploring the possibility
(but, as Stephen noted, no impls yet) of a single interaction between
issuer and holder creating multiple artifacts. Probably this would not be
used for things with different semantics; you wouldn't issue a driver's
license and a passport in one round trip. But perhaps you would want the
same interaction to issue both a V1 and a V2 version of the cred in format
X? Or perhaps you would want the same interaction to issue one cred in both
formats X and Y?

On Thu, Jan 23, 2020 at 10:33 AM Mike Varley <mike.varley@securekey.com>
wrote:

> Hello CCG, I have a clarification question on the Verifiable Credentials
> spec:
>
>
>
> Can an issuer provide a Verifiable Credential with multiple ‘proof’
> flavours? A proof section with ld-proofs and a proof section with zkp
> parameters, for example? Or should / must these be 2 different VCs?
>
>
>
> I am assuming a presentation would always be in a Verifier acceptable
> type, so only 1 proof flavor, but is that assumption valid?
>
>
>
> Here is the scenario I am considering:
>
>    1. An issuer supports ZKP and LD-proof VC proof types.
>    2. A Holder can manage both ZKP and LD-proof VC proof types (and
>    generate appropriate Presentations)
>    3. Verifier V1 supports only ZKP
>    4. Verifier V2 supports only LD-proof.
>
>
>
> The Holder would obtain from the Issuer a (single) VC object with both ZKP
> and LD-Proof components and store it appropriately. When interacting with
> V1, the Holder could create a ZKP Presentation, and when interacting with
> V2 it could create a LD-Proof Presentation, all based off the same VC
> document.
>
>
>
> I am not trying to proposing anything, I am just asking if there is a
> requirement/assumption/convention currently in place. If I want chocolate
> and mint iced cream, am I looking at one cone or two?
>
>
>
> Thank-you!
>
>
>
> MV
>
>
>
> ---
>
> Mike Varley
> mike.varley@securekey.com
>
> Architect – Office of the CTO
>
> SecureKey Technologies Inc.
>
>
>
>
>
>
>
>
>
> This email and any attachments are for the sole use of the intended
> recipients and may be privileged, confidential or otherwise exempt from
> disclosure under law. Any distribution, printing or other use by anyone
> other than the intended recipient is prohibited. If you are not an intended
> recipient, please contact the sender immediately, and permanently delete
> this email and its attachments.
>