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>
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.
>


-- 

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

*Schedule a Meeting: **https://calendly.com/swcurran
<https://calendly.com/swcurran>*