Re: Multi-sig credentials?

Yeah the first external auditing option you mentioned is what we have been
trying out.
But that basically confirms that the way we are trying is reasonable, and
no need to make it more complicated.
I had just never seen a VC as an attribute inside a single signer VC
before, so just had to try it out.
ᐧ

On Tue, Jul 14, 2020 at 1:28 PM Kyle Den Hartog <kyle.denhartog@mattr.global>
wrote:

> Blinded threshold signatures wouldn’t be a good fit for a use case like
> that. Instead, this would be an example where a single issuer would likely
> make more sense. For example, if I were to design this system, I’d likely
> want the person who performs the checks on behalf of the school to be
> internally logged assuming it was built for internal auditing.
>
> In the case where external auditing is necessary, this may be a good case
> for making a VC an attribute of another VC within the credentialSubject
> field, where the first attribute is signed by the person who performed the
> check on behalf of the school and the then school signs the VC with it
> contained in it.
>
> If you wanted to use some fancier crypto though, a regular threshold
> signature (BLS signature which is unblinded) would be a good option
> instead. However, I’m not certain the example you provided would warrant
> using something heavier like this given the tradeoffs you’d likely
> encounter because of it.
>
> - Kyle
>
>
>
> *From: *Snorre Lothar von Gohren Edwin <snorre@diwala.io>
> *Sent: *Tuesday, July 14, 2020 10:19 PM
> *To: *Kyle Den Hartog <kyle.denhartog@mattr.global>
> *Cc: *Manu Sporny <msporny@digitalbazaar.com>; Credentials CG
> <public-credentials@w3.org>
> *Subject: *Re: Multi-sig credentials?
>
>
>
> I just want to shoot in another use case where there might be an obvious
> solution that I dont know about.
>
> That is a course certificate, or a grade certificate.
>
>
>
> This is usually issued by the school itself. The school is the
> representing DID/group.
>
> But it is also signed but the person who basically checked the records and
> approved this student to be elgible for passing.
>
> This person is an important factor for having some kind of accountability
> on who said this was OK.
>
> Is that internal audit, or should it be external audit, meaning the
> teacher/administrator or teacher(s)/administrator(s) who clicked the button
> should be represented in a VC?
>
>
>
> Should the school DID be the single issue/signatory, or the group as Kyle
> represents it as.
>
>
>
> And the audit of who accepted this certificate to be issued is covered by
> blinded treshold signatures?
>
>
>
>
>
> ᐧ
>
>
>
> On Tue, Jul 14, 2020 at 4:04 AM Kyle Den Hartog
> <kyle.denhartog@mattr.global> wrote:
>
> 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.
>
>
>
>
> --
>
> *Snorre Lothar von Gohren Edwin*
>
> Co-Founder & CTO, Diwala
>
> +47 411 611 94
> www.diwala.io
>
>
>
> 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.
>
>

-- 

*Snorre Lothar von Gohren Edwin*
Co-Founder & CTO, Diwala
+47 411 611 94
www.diwala.io