Re: Proof flavours in Verifiable Credentials

Hello,

You need to be inclusive, not fat fingering.

Thanks,

Adeel

On Fri, 24 Jan 2020 at 11:10, Kyle Den Hartog <kdenhar@gmail.com> wrote:

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

-- 
Thanks,

Adeel Ahmad
m: (+44) 7721724715
e: aahmad1811@gmail.com