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