Re: Proof flavours in Verifiable Credentials

Hi Kyle,
I agree that an interesting feature of the VC data structure would be to allow for “all the proof information required for different formats” to be included in a single document, to avoid a situation where multiple VC documents that are supposed to have may be inconsistent (which would likely be a software bug, but these still happen) – but I believe the current state is to have one VC per proof format to avoid possible other exposures/security concerns/ and so on. My understanding is that there hasn’t been enough investigation into supporting multiple proof formats in one VC for now, so it should be avoided.

If the above is contradictory to anyone’s current understanding or expectation of the VC spec I’d be interested to hear more!

MV

From: Kyle Den Hartog <kdenhar@gmail.com>
Date: Friday, January 24, 2020 at 6:08 AM
To: Mike Varley <mike.varley@securekey.com>
Cc: "daniel.hardman@evernym.com" <daniel.hardman@evernym.com>, "public-credentials@w3.org" <public-credentials@w3.org>
Subject: Re: Proof flavours in Verifiable Credentials

I suspect the solution to making sure the data is equivalent in each form of VC will be irregardless of if they're sent separate or together. In fact I suspect it will be easier to do it if they're sent together because it's likely to just be the variable being passed (same bytes in memory) to different signature functions. I'm also unsure if the solution to this is one that's technical. It may leverage technical features, like revoking a credential, but in my mind it's very similar to fat fingering data as it's entered into a system. It will likely be more efficiently solved via in person, social processes for now.
Kyle Den Hartog

On Fri, Jan 24, 2020 at 9:49 AM Mike Varley <mike.varley@securekey.com<mailto:mike.varley@securekey.com>> wrote:
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<mailto:daniel.hardman@evernym.com>>
Reply-To: "daniel.hardman@evernym.com<mailto:daniel.hardman@evernym.com>" <daniel.hardman@evernym.com<mailto:daniel.hardman@evernym.com>>
Date: Thursday, January 23, 2020 at 3:34 PM
To: Mike Varley <mike.varley@securekey.com<mailto:mike.varley@securekey.com>>
Cc: "public-credentials@w3.org<mailto:public-credentials@w3.org>" <public-credentials@w3.org<mailto: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.