Re: Multi-signature Verifiable Credentials

On Tue, Oct 11, 2022 at 8:24 AM Dave Longley <dlongley@digitalbazaar.com>
wrote:

> Another option is to actually hide all the details around how a
> special signature is produced from verifiers and, instead, expose a
> simple signature for verification. In other words, design your system
> such that there is a key hidden away in an HSM that will only perform
> a signature if you send it (or it eventually "collects") whatever it
> needs (be that M-of-N other signatures or anything else). You are then
> able to implement this however you want to -- and avoid exposing those
> details to every external (and perhaps unknown) verifier, in the hopes
> that they will all implement your complex verification scheme.
>

This is the design pattern that Bitcoin has adopted in the latest consensus
soft-fork called "taproot", and also we are puzzling through it for our own
Gordian Envelope CBOR redactable triple-store (see demo at
https://github.com/BlockchainCommons/envelope-cli-swift/blob/master/Transcripts/1-OVERVIEW-TRANSCRIPT.md
)

In bitcoin taproot, there are two parts:

* The first is a simple "optimistic" proof with a only single signature for
verifiers (Schnorr). However, in fact, this "single" signature may be from
an off-chain non-accountable multisignature threshold (i.e. you don't know
who joined the threshold, just that the final signature is valid).

aka:

On Sat, Oct 1, 2022 at 11:54 AM Manu Sporny <msporny@digitalbazaar.com>
wrote:

> * Using a single proof to perform privacy-preserving M of N  threshold
> multi-signature.
>

* a second is a hash tree of proofs, where lots of different business
processes can be involved in offline, including both accountable (you know
who signed) and non-accountable proofs.

Currently, in our Gordian Envelope POA (proof of architecture) all of our
signatures are single signature Schnorr, but you must presume that they
likely were generated from a threshold quorum, not a single private key
(note that quorum may not be multi-person, for instance, it might be an MPC
key ceremony between a hardware key, mobile software wallet key, and an
online service key, all controlled by a single person).

We also considering allowing for #SmartSignatures as well, which are
script-like rules for signatures where the script is part of the signature,
which parallels the 2nd half of bitcoin taproot.

I consider crypto-conditions to be one form of #SmartSignature. For more on
#SmartSignatures my video https://www.youtube.com/watch?v=E9sbWKbfyJU or
transcript:
http://diyhpl.us/wiki/transcripts/blockchain-protocol-analysis-security-engineering/2018/2018-01-24-christopher-allen-smart-signatures/
or my RWOT paper:
https://github.com/WebOfTrustInfo/rwot2-id2020/blob/master/final-documents/smarter-signatures.pdf

If you are interested in participating in a developer community working
through these various multi-party computing approaches for credentials,
contact me.

-- Christopher Allen