Multiple Issuers supported?

[anthonycamilleri]

We have a use case whereby degrees are jointly awarded in collaboration by two or more universities. In this case there are multiple issuers, which could theoretically all add their signature to the proof. The standard seems a bit vague as to whether an entity made up of multiple issuers would be supported.

[dmitrizagidulin]

Hi @anthonycamilleri. At the moment, the spec requires that a VC must have a single issuer (a URL or a single object with an id).
That said, you can probably model it as a complex object that reflects the joint/collaboration nature of the credential. So, it would still have a single id (that represents the collaboration itself), but you'd list the participating organizations. Something like:

{
  "@context": [
    "https://www.w3.org/2018/credentials/v1",
    "https://www.w3.org/2018/credentials/examples/v1"
  ],
  "id": "http://example.edu/credentials/3732",
  "type": ["VerifiableCredential", "UniversityDegreeCredential"],
  "issuer": {
      "id": "... url to a 'joint partnership' page, or a urn id that's a hash of the participants...",
      "type": "SomeJointDegreeCredential", // defined by the community
      "name": "University of A, The Royal College of B",
      "participant": [
         "https://universityA.edu",
         "did:web:royalcollegeofb.edu"
      ]
   },
  "issuanceDate": "2010-01-01T19:23:24Z",
  "credentialSubject": {
    "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
    "degree": {
      "type": "BachelorDegree",
      "name": "Bachelor of Science and Arts"
    }
  },
  "proof": {
      // Add signatures from both participants here.
   }
}

Things to keep in mind: In terms of interop, your main question is to ask - which wallet and verifier software supports my "multiple joint issuers" use case?
Because the example above is a valid Verifiable Credential. That doesn't mean all wallets or verifying software will know how to interpret it.

Thanks for raising the question.

[ghuang123]

The current VC model supports one issuer per Verifiable Credential. One possible solution, the Verifiable Presentation can be used with a presentation graph and proof graph. For real estate settlement case, the Verifiable Presentation may contain the following Verifiable Credentials：The buyer, the seller, the settlement agent, the lender of the buyer, the lender of seller. The Subject for each VC is the House for sale. The cryptography signature scheme such as BLS signature (https://crypto.stanford.edu/~dabo/pubs/papers/BLSmultisig.html) can be leveraged to aggregate the signature from each issuer to generate a single signature and presented by Verified Presentation as a form of proof. The settlement agent can be the issuer to present the Verifiable Presentation to the Verifier.

There is another approach that will need to extend the VC model to allow multiple issuers for the same VC.

[brentzundel]

If this issue results in spec changes, they would be substantive. If there are folks interested in pursuing changes to the specification in response to this, please comment to that effect and we will label this as a v2 issue. Otherwise we will close the issue.

[brentzundel]

No engagement since being marked pending close. 7-day window has elapsed. Closing.