Re: Multi-signature Verifiable Credentials

Yes me too - keen to understand how the same credential can have multiple proof methods - especially when one of them is selective disclosure 

Steven Capell
Mob: 0410 437854

> On 19 Oct 2022, at 3:35 am, John, Anil <anil.john@hq.dhs.gov> wrote:
> 
> 
> Speaking as a “Real, Live Customer” the following is what I am looking for:
>  
> The ability to simultaneously have 3 separate proofs associated with the same JSON-LD based verifiable credential
> A proof that is using FIPS Compliant Cryptographic Primitives
> A proof that is using Post-Quantum Cryptographic Primitives
> A proof that is using BBS Cryptographic Primitives for Selective Disclosure
> A mechanism for the Digital Wallet to signal to an Issuer that it is capable of supporting the above
> A mechanism for the Digital Wallet to signal to a Verifier about the proof formats it has available on a particular credential
> A mechanism for the Verifier to signal to the Holder/Wallet about the proof formats it supports
>  
> Intent
> Cryptographic agility / flexibility to transition to new primitives without the holder being impacted
> Ability to have a FIPS compliant baseline for cryptography as a default while at the same time supporting “experimental/standards-track” cryptography that counter-parities may support on a faster timeline
>  
> Best Regards,
>  
> Anil
>  
> Anil John
> Technical Director, Silicon Valley Innovation Program
> Science and Technology Directorate
> US Department of Homeland Security
> Washington, DC, USA
>  
> Email Response Time – 24 Hours
>  
> 
>  
> From: steve.e.magennis@gmail.com <steve.e.magennis@gmail.com> 
> Sent: Tuesday, October 18, 2022 10:44 AM
> To: 'Snorre Lothar von Gohren Edwin' <snorre@diwala.io>; 'Jack Tanner' <jack@tonomy.foundation>
> Cc: 'Manu Sporny' <msporny@digitalbazaar.com>; public-credentials@w3.org; rebal@tonomy.foundation; 'Suneet Bendre' <bendre.android@gmail.com>
> Subject: RE: Multi-signature Verifiable Credentials
>  
> CAUTION: This email originated from outside of DHS. DO NOT click links or open attachments unless you recognize and/or trust the sender. Contact your component SOC with questions or concerns.
>  
> Snorree, the scenario you describe regarding potential future dissonance highlights an important consideration. VC’s are great for preserving the intent of one or more parties *at a given point in time* if that intent later changes then you need to think in terms of revocation/re-issuance or modification of a VC. Multi-sig can potentially give you a little flexibility by allowing some issuers to change their intent while others do not, but I don’t think M of N is the best way to deal with it.
>  
> -S
>  
> From: Snorre Lothar von Gohren Edwin <snorre@diwala.io> 
> Sent: Tuesday, October 18, 2022 6:52 AM
> To: Jack Tanner <jack@tonomy.foundation>
> Cc: Manu Sporny <msporny@digitalbazaar.com>; public-credentials@w3.org; rebal@tonomy.foundation; Suneet Bendre <bendre.android@gmail.com>
> Subject: Re: Multi-signature Verifiable Credentials
>  
> I would love to understand what customers are asking for to translate this logic into human needs.
> 
> Because we are facing a situation where credentials have had the Presidents signature on them(physically) and that was a verification mechanism in this ecosystem. But in reality, adding this signature together with the institute signature inside the VC, will add a potential future dissonance. Because the President might have quit, and it might not make sense any more. Unless you mix in timestamps and so on.
> 
> What I have been reasoning about is the question, does this signature need external auditability? Yes? Put it in the VC. No? Leave it.
> While for most cases, the institute signature is enough, and if one ever wants to dispute a credential, there is an internal audit that has to make sure it was not a bad actor move or something else.
> 
> What are your thoughts on this?
> 
> Also why Im trying to learn what real live customers are asking for and what mental model I can wrap around what we are discussing here.
> ᐧ
>  
> On Mon, Oct 3, 2022 at 12:18 PM Jack Tanner <jack@tonomy.foundation> wrote:
> For the cases that we are looking at
> * Using multiple proofs to perform set-based multi-signature. (we want to be able to asynchronous sign the VC)
> * Using multiple proofs to perform chain-based multi-signature.
> * Using multiple proofs to perform multi-level/enveloped multi-signature.
> * Using a single proof to perform set-based multi-signature. (sign a VC with a number of keys at once)
> * Using a single proof to perform chain-based multi-signature.
> * Using a single proof to perform M of N threshold multi-signature. (we are using W3C's Verifiable Condition to express this condition in the DID Document)
> * Using a single proof to perform privacy-preserving M of N  threshold
> multi-signature.
>  
> Food for thought, the implementation we just finished with JWT's is a kind of chain proof in the end to make it comply to the JWT standard - we nested each JWS as the payload for the next JWS inside the JWT.
>  
> Proof sets for JSON-LD format is also a great approach.
>  
> Cheers,
> Jack