Re: Proof flavours in Verifiable Credentials

Ok, thanks Daniel.
I think it makes sense for a VC to be of one self-contained proof format, and if a Holder needs multiple they can ask for multiple. Especially for a version 1.0.

The benefits and pitfalls of combining proof methods (and what that means) in one VC container format likely need to be carefully considered before we try and build in that “optimization”.

Thanks
MV

From: Daniel Hardman <daniel.hardman@evernym.com>
Reply-To: "daniel.hardman@evernym.com" <daniel.hardman@evernym.com>
Date: Thursday, January 23, 2020 at 3:34 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 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<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.