Re: Multi-sig credentials?

There's a few tradeoffs that I'd point out when it comes to single-issuer /
single-signer VCs:

A non-exhaustive list of advantages are:

   1. It's easier to build a flow like this using more mature aspects of
   the ecosystem already defined such as how to issue and verify a credential
   over things like CHAPI, DIDComm, OIDC, etc.
   2. Issuer correlation is explicit (more on when you might not want this
   below)

A non-exhaustive list of dis-advantages are:

   1. This requires the holder to go collect VCs from more issuers (meaning
   discovery, collection, and storage can be a bit more difficult in a limited
   set of cases - but not impractical)
   2. This makes the amount of data sent to a verifier redundant and larger
   (e.g. I'm redundantly sending the same credentialSubject data, but with new
   signatures for each one from different issuers - the ZKP verifiable
   presentation nullifies this problem by allowing credentials to be
   aggregated together in a proof though)
   3. It limits capabilities of issuers which more advanced cryptography
   can help with (see below for a use case)

In general, *I find that Manu is correct though that using single-issuer /
single-signer flows can address most of what's needed* and in the case
where multiple issuers are needed the holder can just gather multiple
credentials and present them together to the verifier.

As an example where multi-signatures using advanced crypto may be useful
think of this use case:

A group of issuers want to get together and issue a credential. They set
two requirements. The first requirement is that the issuer of the
credentials must be the group rather than multiple individual participants
representing the group. This is because they want the group to be the
authority not any particular individual participant of the group.
Furthermore, there's a second requirement that due diligence should be done
by multiple parties of the consortium and they must all sign off, without
explicitly linking to who performed the verification. In this case
blinded-threshold
signatures <https://www.jstor.org/stable/27751059?seq=1> can address this
use case in a way that would best fit the requirements of the (theoretical)
use case and using multiple credentials wouldn't meet the first
requirement. I'm sure there's other use cases that are similar to this, but
as Manu pointed out they're likely to be very limited and in general the
holder collecting multiple credentials should be the preferred path.

However, even in the limited cases where this may be necessary its possible
that an LD Proof suite can be defined to do so and in my opinion would be
the preferred path.

On Tue, Jul 14, 2020 at 11:54 AM Manu Sporny <msporny@digitalbazaar.com>
wrote:

> On 7/13/20 10:58 AM, Keerthi Thomas wrote:
> > In a paper based approach, it is relatively straightforward, signatures
> > are obtained serially.
>
> Note that Linked Data Proofs have supported unordered set signatures and
> ordered set signatures for a number of years now:
>
> https://w3c-ccg.github.io/ld-proofs/#multiple-proofs
>
> The Veres One DID Method uses set signatures for writing DID Document
> operations to the ledger, where the first signature is a proof to assert
> that you have the authority to write to the ledger and the second is a
> proof that you are the DID controller.
>
> That said, multi-sig use cases are often more complex than they need to
> be and when you break down the use case, the sort of verifiable
> credential being issued is slightly different. That is, what we do on
> paper is often bad data modelling, and we can be more precise in the
> digital world.
>
> I suggest you try to solve your problem by using simple single-issuer /
> single-signer VCs. We have come across very few use cases that require
> multisig -- including the use case that I think you're asserting needs
> to be solved with a multisig.
>
> If you find that you absolutely need multisig, LD Proofs can do it (set
> or chained).
>
> -- manu
>
> --
> Manu Sporny - https://www.linkedin.com/in/manusporny/
> Founder/CEO - Digital Bazaar, Inc.
> blog: Veres One Decentralized Identifier Blockchain Launches
> https://tinyurl.com/veres-one-launches
>
>
>

-- 
This communication, including any attachments, is confidential. If you are 
not the intended recipient, you should not read it - please contact me 
immediately, destroy it, and do not copy or use any part of this 
communication or disclose anything about it. Thank you. Please note that 
this communication does not designate an information system for the 
purposes of the Electronic Transactions Act 2002.