Re: Proof flavours in Verifiable Credentials

Thanks Stephen, so for Aries the communication channel (DIDComm) allows for multiple VC attachements, but each VC would be a distinct format – is that an accurate understanding?

Thanks!

MV

From: Stephen Curran <swcurran@cloudcompass.ca>
Date: Thursday, January 23, 2020 at 12:44 PM
To: Mike Varley <mike.varley@securekey.com>
Cc: "public-credentials@w3.org" <public-credentials@w3.org>
Subject: Re: Proof flavours in Verifiable Credentials

In the Aries protocols, we've included some capabilities in support of that use case:

1. There is the possibility of negotiation in the issuing process between the issuer and the holder on that cover (amongst other things) the format (flavour) of the credential. There are "proposal" (from holder) and "offer" (from issuer) messages that enables such back-and-forth.
2. There is likewise negotiation between the verifier and the holder/prover.
3. The issue credential messages are defined with the credential details in arrays of attachments so that (a) the details of the credential formatted can be abstracted away from the exchange/messaging mechanism via attachments, and (b) multiple credential formats can be issued for the same logical credential (the array).

Note that while that is the theory and intention, I'm not aware of any implementations that have taken advantage of that capability. Right now, production Aries use cases all (AFAIK) use Indy ZKP credentials.

On Thu, Jan 23, 2020 at 9:33 AM Mike Varley <mike.varley@securekey.com<mailto: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:

a.       An issuer supports ZKP and LD-proof VC proof types.

b.      A Holder can manage both ZKP and LD-proof VC proof types (and generate appropriate Presentations)

c.       Verifier V1 supports only ZKP

d.      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<mailto: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.


--

Stephen Curran
Principal, Cloud Compass Computing, Inc. (C3I)
Technical Governance Board Member - Sovrin Foundation (sovrin.org)

Schedule a Meeting: https://calendly.com/swcurran