Re: Proof flavours in Verifiable Credentials

Yes. The DIDComm channel takes no opinion on what you are passing along,
and the use of attachments means that the credential exchange protocol
messages likewise don't care.  The received message will be passed to
handlers that will (hopefully) understand the formats and process them
accordingly.  So it will come down to what handlers your agent supports,
and that you should be able to express during the negotiation prior to
issuance and presentation.

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

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


-- 

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