RE: Multi-signature Verifiable Credentials

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

[A picture containing graphical user interface  Description automatically generated]<https://www.dhs.gov/science-and-technology>[/Users/holly.johnson/Library/Containers/com.microsoft.Outlook/Data/Library/Caches/Signatures/signature_1972159395]

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<mailto: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