Representing Multi Issuer Credentials in the VCDM

[decentralgabe]

As per the discussion at TPAC on September 16:

Overview

Multiple issuers: where there are multiple DID or URI represented issuers of a credential to a single (or multiple) parties.

This issue mostly lays out information. I'm interested in what the community thinks, and moving towards a concrete proposal (with suggestions from you).

Related To

• Representing Mutli Subject Credentials in the VCDM #931
• Representing Delegated Credentials in the VCDM #930

Prior Art

• If you have some, please share.

Use Cases

• NFTs from a smart contract (contract address vs minter address?)
• Co-tweets
• Parent's claims about their children
• Treaties, nuclear launch codes
• Co-signing for a loan

What Would It Look Like?

Questions

• Should credentials with multiple issuers even be allowed?
• What alternatives are there?
• How can this be represented in JWTs, Data Integrity Proofs?
• Do existing selective disclosure/ZKP schemes support this construction?

[decentralgabe]

Mentioned this in the issue around multiple subjects, but had some more thoughts after TPAC to address the approach described last Friday:

One point that @SmithSamuelM raised at TPAC (though relating to multiple issuers, not multiple subjects) was that a single DID can be used to represent multiple parties, if those parties agree to a representation scheme under a single DID (e.g. a multisig, multiple controllers, or something else). I believe this is a possible method of cleverly allowing multiple subjects (or issuers!) in a credential; however I am worried that this approach has two clear downsides:

1. It is not immediately clear in reading a credential who the subject(s) are. Many DIDs may have related keys/DIDs in them controlled by a single entity. It would be exceedingly difficult to determine cases of multiple subjects, or subjects who just have a bunch of identities.
2. DIDs with multiple keys/related IDs can change. This can harm the verifiability/integrity of a credential. For example, if I issued a credential to a single DID (did:example:alices-multisig) comprised of two parties (lets say did:example:alice and did:example:bob) and 6 months post-issuance Alice reforms her multisig to include new parties and remove Bob lets say did:example:alices-multisig now contains did:example:alice, did:example:charlie, and did:example:dave) is the credential to still be seen as valid?

Moving past that example. I'd like to gain a sense of folk's appetite for firming up the existing language around multiple subjects and introducing normative statements for the representation of multiple subjects in a single credential, expanding on the existing spec text and example here.

[RieksJ]

This is not just technically adding things, but much more about its meaning. I would like to think that an issuer-signature over credential-data can be used to identify the party on whose behalf an actor has signed the credential. Not just so that a verifier can question (perhaps also: sue) this party if so needed. There should be no more than one party, because a verifier would not be able to decide which of them would provide the authoritative answer to such questions (or would be suable).

In a use-case where it would be beneficial for all members of a community to all sign a credential, I would say that the community (which is a party) should sign it.

In a use-case where an arbitrary set of parties would sign it (perhaps a petition), I would say that each of them sign their own copy of a credential that states the same.

I can imagine that the signature of different parties might be part of a credential, but NOT as an issuer-signature. An example is provided in the decentralized governance paper, that shows how parties can be certified/accredited to issue certain kinds of credentials, and embed this certificate in the VCs that they issue, enabling others to verify that the issuer has been certified.

Let's not keep extending VCDM with all sorts of technical features that might bring (slight) benefits (at the technical level) and huge problems at the business/information/actual usage level.

[decentralgabe]

@RieksJ

There should be no more than one party, because a verifier would not be able to decide which of them would provide the authoritative answer to such questions (or would be suable).

This is similar to the confusion that has come up with holder/subject/prover. The answer from us must be clearer language to express possibilities, such as:

To be valid a verifier must receive authorization from:

1. one of the issuers
2. a quorum of issuers
3. all issuers

Whether such language should be defined in the data model itself or in an additional authorization framework is a good question. I'm considering that the data model shall provide flexibility which can be clarified and further specified by higher levels of abstraction.

Let's not keep extending VCDM with all sorts of technical features that might bring (slight) benefits (at the technical level) and huge problems at the business/information/actual usage level.

I strongly disagree with this statement. The goal of the VCDM is to accurately represent credentials at the data model level. I do agree with you that the line today is blurry between the data model itself and how this maps to business/information/actual usage -- curious what @msporny and @OR13 have to say here.

[David-Chadwick]

We have many examples today of multiple signatures on documents, both concurrent signing and sequential signing. An example of the former is a cheque (US check) that needs multiple signatures. An example of the latter is when a witness signs a document after the contractual party has signed the document. So we should cater for both of these in the VC DM. In the NGI Atlantic project we are working on this problem in the context of JWT proofed VCs. Serial signing does not require any changes to the JWT signing procedure, since the JWT output from the first signing can be used as the payload for the second signing. This process can be recursed as often as required. So I think it would be quite easy to describe this in the DM. For concurrent signing we propose to use JSON Web Signature JSON Serialization from RFC 7515 as we do not believe that the compact serialisation is required for such a document.

[OR13]

{
      "payload":
       "eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGF
        tcGxlLmNvbS9pc19yb290Ijp0cnVlfQ",
      "signatures":[
       {"protected":"eyJhbGciOiJSUzI1NiJ9",
        "header":  {"kid":"2010-12-29"},
        "signature":
         "cC4hiUPoj9Eetdgtv3hF80EGrhuB__dzERat0XF9g2VtQgr9PJbu3XOiZj5RZ
          mh7AAuHIm4Bh-0Qc_lF5YKt_O8W2Fp5jujGbds9uJdbF9CUAr7t1dnZcAcQjb
          KBYNX4BAynRFdiuB--f_nZLgrnbyTyWzO75vRK5h6xBArLIARNPvkSjtQBMHl
          b1L07Qe7K0GarZRmB_eSN9383LcOLn6_dO--xi12jzDwusC-eOkHWEsqtFZES
          c6BfI7noOPqvhJ1phCnvWh6IeYI2w9QOYEUipUTI8np6LbgGY9Fs98rqVt5AX
          LIhWkWywlVmtVrBp0igcN_IoypGlUPQGe77Rw"},
       {"protected":"eyJhbGciOiJFUzI1NiJ9",
        "header": {"kid":"e9bc097a-ce51-4036-9562-d2ade882db0d"},
        "signature":
         "DtEhU3ljbEg8L38VWAfUAqOyKAM6-Xx-F4GawxaepmXFCgfTjDxw5djxLa8IS
          lSApmWQxfKTUJqPP3-Kg6NU1Q"}]
     }

https://www.rfc-editor.org/rfc/rfc7515#appendix-A.6.4

Notice the missing alg... Not sure how much actual interop there is here... cc @selfissued @Sakurann @dwaite

Is JWS multisignature well supported today? What are some pitfalls? Is there a compact serialization?

[OR13]

Here is part of the answer from the test vectors RFC: https://www.rfc-editor.org/rfc/rfc7520#section-4.8

Since this example contains more than one signature, only the JSON General Serialization is possible.

^ This would require a normative text change.... and probably the ability to do something like vc-jws... since I don't know if JWTs support this.

[SmithSamuelM]

@David-Chadwick Recursive Serial Signing works for endorsements where a later signer signs the signed payload from a previous signer, but it is problematic for thresholded multi-sig where the signing must not be ordered and the signers do not sign each others signed payload.

[decentralgabe]

Would it be reasonable to add normative spec language describing how to construct a multi-issuer credential and leave 'securing' to the Data Integrity and VC-JWT specs? It sounds like there are solutions for both camps.

[SmithSamuelM]

There are lots of ways to skin this cat. The most complicating factor is that in the current VC Data Model the proof is part of the VC instead of either an attachment to the VC or included in a proof envelope as a sibling to the VC in such an envelope. When not part of the VC but attached or as a sibling, then the conveyance and syntax of any proof or set of proofs such as multi-sig are independent of the VC itself. This lends itself to using a different spec for the proof data model. But when the proof is part of the VC itself then serializing the VC in a way that removes the proof so that the proof can be computed on the VC sans proof ( because the proof can't be computed recursively on itself), becomes more complicated for multi-sig proof types. The VC spec must then include a normative way to calculate the proof for every possible proof type. Its entirely possible, just more complicated. In a VC Version 2, separating the proof from the VC would greatly simplify things and IMHO is a reason to have breaking changes vis-a-vis VC version 1.

Such a separation would enable the asynchronous generation and verification of proofs. This is a huge advantage at scale and one of the main reasons ACDC separates the two.