Re: Multi-sig credentials?

Just starting to learn from the group. I second this use case Snorre
is bringing. Also, I would like to know how the VC would be enabled to keep
track of curriculum related objects like student learning objectives.

I believe having that level of granularity in the VC would ultimately
enable using VC's as a method for assigning 'credit' as in the US Education
system.

Warmest,


George

On Tue, Jul 14, 2020 at 3:22 AM Snorre Lothar von Gohren Edwin <
snorre@diwala.io> wrote:

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


-- 
~ George | 206.953.6231