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

• https://github.com/w3c/vc-data-model/issues/931
• https://github.com/w3c/vc-data-model/issues/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?

[dwaite]

Yes, such as analogous real world credentials like marriage licenses, birth certificates, and treaties. It does not make sense to jam our concept of DID into the real world and say "well just go get a joint DID" because that's not what the VCDM is about. The VCDM intends to represent credentials, and there are numerous real world cases where multiple parties are issuers of the same credential. This is a truism about credentials that I don't believe should be up for debate.

Would this not imply a much larger change than just turning issuer into a set?

I would not expect from your scenarios that it would only a matter of having multiple issuer identities (and supporting proof infrastructure). I would expect that each issuer could attach their own conditions for validity onto the credential. For instance, how would a single credentialStatus work with multiple issuers?

The verifier does need to still understand credential validity and lifecycle, and the validity rules for high value credentials is hopefully not ad-hoc. Multi-party issuance requires even more coordination, and such policy needs to be understood for the validity of credentials to be quantified. This is why I am trying to understand if this can be captured within the proof section, even if that means a single issuer 'identifier' is then referring to more of a process or framework than to a specific party. And no, it doesn't need to be a DID.

However, I also suspect some of these scenarios do not require multi-party representation. For example - if the witnesses for a marriage license are unable to serve any official capacity such as changing my taxation structure, imparting new legal rights, or revoking said license, were they actually an issuer? Or did they provide a statement (possibly in the form of a verifiable credential) to the more broadly accepted issuing authority, and were potentially captured as such within evidence or as a predicate?

[decentralgabe]

how would a single credentialStatus work with multiple issuers?

it would make sense to define a credentialStatus property that has multi-issuer support. that's what extensibility is all about!

The verifier does need to still understand credential validity and lifecycle, and the validity rules for high value credentials is hopefully not ad-hoc

correct, as they do today in the real world with multi-issuer credentials

Re your marriage example: I don't believe the witnesses are the issuers, the county recorder's office is (at least in the US). Witnesses attestations would be considered evidence like you suggest. I was referring to the couple to be wed's signatures on the application for a marriage license as a multi-issuer credential, sorry I did not make this clear.

I'm certain we can find ways around this, but I wonder if that's our job to tell the world how credentials ought to be represented, instead of being flexible to the many real world credentials and behaviors that exist today.

[dlongley]

@decentralgabe,

I think the problem here is that it seems insufficient to just modify the issuer property to accept a set of values instead of a single value in order to address the use cases. Given that its sufficiency to address the use cases hasn't yet been demonstrated, it doesn't yet make sense to change the data model. Changing it before we know if it works can lead to churn, broken implementations, and more problems for us to solve.

Another way of putting this is: yes, there is some separation between securing the data model and the data model itself, but they are connected. Every use case requires securing the data model. So, if we change the data model to address a use case from a modeling perspective, but in so doing render it too difficult to secure, then we will just fail the use case from a security perspective. We can't give people half of a solution.

Additionally, there are other ways of addressing the use cases that have been mentioned and are being explored. I think there's rough consensus that the use cases are valid. Where we don't yet have rough consensus is on the mechanism we ought to use to address them.

I'm certain we can find ways around this, but I wonder if that's our job to tell the world how credentials ought to be represented, instead of being flexible to the many real world credentials and behaviors that exist today.

I agree we shouldn't be dismissive of the use cases. However, we should question whether a sort of skeuomorphic approach to this problem is appropriate, whereby we try to mirror exactly what's going on with physical credentials today vs. just ensuring the technology does indeed address the use case.

[iherman]

The issue was discussed in a meeting on 2023-02-01

• no resolutions were taken

View the transcript

#### 4.1. Representing Multi Issuer Credentials in the VCDM (issue vc-data-model#932) _See github issue [vc-data-model#932](https://github.com/w3c/vc-data-model/issues/932)._ **Kristina Yasuda:** Issue 932.. Can anyone talk about this specific issue about multi-issue credentials?. **Manu Sporny:** At a high level, this is about whether a VC can have multiple issuers.. … It's a bit deeper than it sounds. On the data model level, of course we could have an array. But then it's not clear what you do with the proofs.. … Perhaps we want the issuer to be a single field (like it is today), and then have multiple signatures. … You may have one primary issuers but 'n' signatures on the credential.. … And then there's the argument that we shouldn't complicate the ecosystem. When you have multiple issuers, ultimately there needs to be an issuing authority.. … E.g. you have multiple schools in a district that test the students, but you only have one authority that issues the credentials.. … There are different aspects on what this is about, and Gabe is leading the discussion.. > *Dave Longley:* or just issue two (or N-many) VCs ... need clear use cases and how those could / ought to be solved. **Kristina Yasuda:** We discussed mechanisms such as chaining, I think GS1 has something in production with multiple issuers.. … Do we want to define how the multiple issue scenario would work, and if yes which mechanisms do we want to use.. **Gabe Cohen:** I see signing as a separate concern as the data model. It's important to clarify the data model first, if there can be multiple signatures.. … A multi signature scheme could be used, or having multiple proofs. I think there is still work to be done in crypto suites.. … I think the requirement is solid, I believe there are situations where single credentials are signed by multiple parties, and the spec text should clarify this.. … We can add language to the spec, even if a crypt suite doesn't exist yet.. > *Kristina Yasuda:* orie: +1 Gabe. **Dmitri Zagidulin:** I agree that multiple issuers is a legitimate use case.. … We have a similar situation in the DID data model, we have the notion of multiple controllers in a DID document. … We haven't done much with this mechanism,. … I recommed that we do not model multiple issuers as multiple signatures. … Either change the model to allow multiple issuers, or specify the notion of a compound issuer. … If a student has a diploma from 2 universities, there would be 1 issuer, which is the partnership/combination of the 2 universities.. **Kevin Dean:** The GS1 example is not one of multiple issuers in this sense. > *Dave Longley:* +1 to the notion that there are multiple different ways this problem could be solved and needs further exploration. **Kevin Dean:** The authority to issue a credential is derived from a prior credential. There is a chain of credentials, but this is not the same as having a credential with multiple issuers.. … My authority to issue a final credential in a chain is derived from previous credentials in a chain.. … Going back to private key cryptography in environments where parties don't trust each other.. > *Kristina Yasuda:* orie: +1 Kevin, it's hierarchical. **Kevin Dean:** Control of issuing a final credential is put either into completely unrelated party, or it's under some partial control of one of the parties. This might not be acceptable to others.. … Environment where issuers don't necessarily trust each other, but they want to issue a credential together.. > *Steve McCown:* +1 Kevin. > *Dmitri Zagidulin:* treaties and contracts would be best modeled as a COLLECTION of VCs, from individual issuers. **Kevin Dean:** For treaties, certain contracts, there may well be requirements for multple issuers in low trust environments.. > *David Chadwick:* +1 kevin. **Orie Steele:** I agree with what KevinDeanGS1 said and what decentralgabe said initially. … We have seen several security approaches to this problem. > *Dave Longley:* +1 to dmitri ... that it may be best to model these things as collections of VCs. **Orie Steele:** Going back to what decentralgabe said, the data model is about the intention, and securing it is a separate concern.. … Maybe you're used to OIDC or access tokens, where you have only 1 issuer and 1 subject.. … The core data model should express the actual information that's important. … I feel uneasy how we talk about proofs in relation to the core data model.. … I have a feel we perceive Data Integrity Proofs to be more "imporant" than JWS proofs. … The data model should be expressed in JSON-LD, and then the security aspect should be modeled using the proofs. … I'm aware of some of the work dmitriz mention regarding multiple controllers. … This is not equivalent to a data model that allows expressing multiple issuers. > *Kristina Yasuda:* what is the value of two issuers URIs if there is only one signature?. **Manu Sporny:** The current data model restricts the "issuer" to be a single value. If we just talk about the data model, do we want to loosen that requirement?. > *Dave Longley:* multiple VCs, each signed by a different issuer, could all make the same claim about a credential subject (such as a treaty) ... and merging those together would represent all parties of the treaty signing together, etc. -- options to explore.. **Dmitri Zagidulin:** I think there would be great value if we restrict a VC to a single issuer.. … In the education space, there is a "Comprehensive Learner Record", which is a kitchen sink approach that contains a lot of information. > *Kristina Yasuda:* orie: +1 Manu, it would be a change to the core data model first. **Dmitri Zagidulin:** This can be a single "outer" credential with "nested" credentials. Each one has a single issuer. The "outer" one is signed by an aggregator.. > *Andres Uribe:* +1 to dimitri. > *Kerri Lemoie:* CLR spec: [https://1edtech.github.io/ComprehensiveLearnerRecord/docs/clr_v2p0.html](https://1edtech.github.io/ComprehensiveLearnerRecord/docs/clr_v2p0.html). **Dmitri Zagidulin:** I think we can express these situations while keeping the restriction of having a single "issuer" in the data model. **Kristina Yasuda:** I don't think we're ready for a PR yet. > *Dmitri Zagidulin:* +1 dlongley, re having the /treaty/ itself be the subject of VCs. **Kristina Yasuda:** I encourage continued conversation about the data model aspect of this.. > *Dmitri Zagidulin:* that's the approach taken by our recent RWoT paper. **Kristina Yasuda:** Thank you everyone, see you next week.. ---

[SmithSamuelM]

@dwaite and supporting @dlongley comment that changing the data model requires mechanisms for securing the new data model. One of the main reasons ACDCs as an example uses chaining to to provide secure mechanisms for all sorts of multi-attribution (i.e relationships between issuers of different types and roles.

For example in ACDCs with KERI there are at least two mechanisms for securing the concept of multiple issuers.

The first is a thresholded multi-sig Issuer identifier where each of the keys contributed to the multi-sig threshold comes from yet another identifier. By disclosing the identifiers of the contributors, a verifier can then match the issuers to business logic about their role in that multi-issuance.

The second is a chained ACDC where the presenter creates a bespoke ACDC at presentation that chains back to separate issuances of the same content ACDC from separate issuers. So instead of an list embedded in a VC the multiple issuers are provided via a list of edges that point to ACDCs sourced from the different issuers but which issue to the presenters Identifier and issue the same claims. the difference is the metadata that secures the individual issuances. So the tooling for security does not have to change.

[decentralgabe]

@dlongley

Given that its sufficiency to address the use cases hasn't yet been demonstrated, it doesn't yet make sense to change the data model. Changing it before we know if it works can lead to churn, broken implementations, and more problems for us to solve.

Yes, it should be really clear why making multiple issuers is a sufficient change. I raised these points earlier, but let me try to expand.

Option 1: Single credential, multiple issuers per single issuer identifier

A single conceptual issuer fails with the following considerations:

1. It does not immediately communicate to the holder or recipient(s) of VCs that there are multiple issuers. It requires additional resolution and parsing infrastructure which increases the burden for a credential to be understood.
2. Not all DID methods support multiple parties to be listed. This would be eliminating a broad class of users for multi-issuer credentials.
3. Not all DID methods support historical resolution of DID state. This means that there could be a point-in-time where the DID contained multiple issuers, and that point-in-time could be lost forever. This would make it impossible to know who actually issued the credential and does not at all help further the multi-issuer use case.

Some of these points are present even without multi-issuer use cases, but we should not double down on these shortcomings, and instead create a new pathway to make it abundantly clear that a credential is multi-issuer and clearly communicate the provenance of a credential's issuance.

Option 2: Multiple credentials, single issuer per credential

This approach fails the requirements for a number of real world use cases by increasing complexity and management overhead. We would need a way to normatively link credentials together, that is, to say that this credential is part of a multi-issuer pair. Complex, and confusing for both holders and verifiers--all interactions with these credentials now become a coordination problem.

There are two buckets of use cases that we have certainty we need this functionality for:

1. Where you need multiple signatures to authorize the same legal doc / authorization to take action (e.g., Unanimous Withness Consent, Treaties, DAO actions, application for a marriage license, to adopt a child, or any joint resolution).
2. Where you need multiple signatories, but on different parts of a legal doc / different actions authorized by different signatories to unlock some common thing (e.g. signature by an individual and a notary for a home loan or title).

---

So, if we change the data model to address a use case from a modeling perspective, but in so doing render it too difficult to secure, then we will just fail the use case from a security perspective. We can't give people half of a solution.

Agree, 100%. I think it's a chicken and egg scenario, and I'd advocate for changing the data model first because it is what everything else is built on top of. I do not think we should end up in a scenario where we block changes in the data model because higher layers have not yet demonstrated how they could work with the changes—this leads us to stalemate. We need to be able to innovate here first.

Additionally, we already have indications of how multiple signatures on a single credential can work, at least in some signature representations.

Additionally, there are other ways of addressing the use cases that have been mentioned and are being explored.

I believe these other ways are insufficient as I've outlined above. They cause confusion, have risk of changing from underneath you, and undermine what it means to be "verifiable."

[dlongley]

@decentralgabe,

We would need a way to normatively link credentials together, that is, to say that this credential is part of a multi-issuer pair.

Why?

[decentralgabe]

@decentralgabe,

We would need a way to normatively link credentials together, that is, to say that this credential is part of a multi-issuer pair.

Why?

Without a standard way to do this you lose the value of multi-issuer creds. It's important to know there are multiple issuers from the credential, so that you can check their respective status lists, expirations, terms of use, and so on as may be required in some of these cases.

[dlongley]

@decentralgabe,

Without a standard way to do this you lose the value of multi-issuer creds. It's important to know there are multiple issuers from the credential, so that you can check their respective status lists, expirations, terms of use, and so on as may be required in some of these cases.

I feel that we need to pull this back to first principles as I'm concerned that we keep hitting an erroneous conclusion. This is what I feel like I keep hearing:

1. There are use cases that need some mechanism whereby multiple parties make the same or similar assertions. (Checks out to me).
2. Those use cases could be solved using "multi-issuer credentials". (I don't know, maybe).
3. If we don't have a way to do X with "multi-issuer credentials", then "multi-issuer credentials" won't have value. (If you say so).
4. Therefore, we can't solve the use cases without X. (I think this is an error in reasoning)

The point I keep trying to make is that we should look at one or more specific use cases to see how we could solve them rather than jumping to "we must use multi-issuer credentials to solve the use cases we know are out there and matter, so let's talk about the best way to do that". I'm not convinced that "multi-issuer credentials" is the best way to the solve the use cases yet -- because it doesn't seem like we've fully explored the various ways to do it.

For example, you were just mentioning that there may be cases where N-many parties all need to make the assertion that a particular contract is valid. Well, that could be modeled by having each party issue a VC that says that said contract is valid. A verifier must somehow have a list of parties that they are looking to check to see if they've signed off on the contract -- and they can just run down that list and compare it against the set of VCs.

Now, this isn't a full-blown use case exploration, just a real quick example of how it seems like it could work off of the top of my head. It didn't need "multi-issuer credentials" (for some definition of that). My point is that we need to really deeply explore a particular use case to see what the possible solutions are. And, ideally, we repeat that for a few more use cases to see what's in common. Otherwise, it seems to me like we're caught in a logic loop that that is begging the question over whether "multi-issuer credentials" are the only way to solve the use cases (presuming that they even do at all).

[decentralgabe]

I'd like a response to the options and their critiques I laid out above, but I will say we should separate can and should.

Perhaps many use cases of VCs could be done with centralized solutions (mDL anyone?) or even paper-based solutions as they have been for hundreds of years. This does not mean there isn't a better way to do them with VCs or even multi-issuer VCs. Contorting the data model to "work" for these use cases won't get us anywhere until we agree that there are benefits in using a single credential with multiple issuers.

I agree with you that it's good to go deep on a single use case to start, so let's talk about a Unanimous Witness Consent document and apply the reasoning I linked above.

[dlongley]

@decentralgabe,

You asked me to respond to the options above -- though I do think it's working backwards as I mentioned. I will leave some comments on the options as you asked, but I really do recommend that people look into solving specific use cases first instead of looking at possible problems with possible solutions in the abstract.

Option 1: Single credential, multiple issuers per single issuer identifier

A single conceptual issuer fails with the following considerations:

1. It does not immediately communicate to the holder or recipient(s) of VCs that there are multiple issuers. It requires additional resolution and parsing infrastructure which increases the burden for a credential to be understood.

Why does this need to be communicated at all? Maybe this is a feature, not a bug? This is why specific use cases need to be explored.

2. Not all DID methods support multiple parties to be listed. This would be eliminating a broad class of users for multi-issuer credentials.

You don't have to support this through DID methods. Additionally, mechanisms could be developed that abstract away the details of using any particular key registered with any DID method, including ones that produce static DID docs like did:key. A simple example of this is putting the private key in an HSM that is accessible via WebKMS where access to sign with the key is managed via ZCAPs. More complex examples could be constructed. This is just another example of not exposing the details to verifiers, thereby enabling more existing software to work without any changes.

3. Not all DID methods support historical resolution of DID state. This means that there could be a point-in-time where the DID contained multiple issuers, and that point-in-time could be lost forever. This would make it impossible to know who actually issued the credential and does not at all help further the multi-issuer use case.

This seems orthogonal. Indeed, even if multiple issuers were listed in the same credential, I can imagine ways in which this concern would be unaffected.

Option 2: Multiple credentials, single issuer per credential

This approach fails the requirements for a number of real world use cases by increasing complexity and management overhead. We would need a way to normatively link credentials together, that is, to say that this credential is part of a multi-issuer pair. Complex, and confusing for both holders and verifiers--all interactions with these credentials now become a coordination problem.

We covered this above.

There are two buckets of use cases that we have certainty we need this functionality for:

1. Where you need multiple signatures to authorize the same legal doc / authorization to take action (e.g., Unanimous Withness Consent, Treaties, DAO actions, application for a marriage license, to adopt a child, or any joint resolution).

It seems like the common link here is another agreed upon document that each party could reference in the VC they generated. That same document could list all of the expected signatories. You recommended that this be the particular use case to start chasing down in detail and it's a perfectly good choice.

2. Where you need multiple signatories, but on different parts of a legal doc / different actions authorized by different signatories to unlock some common thing (e.g. signature by an individual and a notary for a home loan or title).

It again seems like different issuers could issue different VCs referencing their sign off on the appropriate parts. In fact, it seems like this would get far more complicated / not be modeled properly if we used "multiple issuers" of the same VC here, but that's just a gut reaction. Again, a good reason that the use cases need to be rigorously explored.

Hopefully this is the response you were looking for. I recommend that people deep dive into the use case you suggested as a way to move the conversation forward around what potential solutions might look like.

[agropper]

Here’s a use-case: https://www.politico.com/newsletters/digital-future-daily/2023/02/09/the-smallest-state-has-the-biggest-blockchain-ambitions-00082118

“…. opening a restaurant in Rhode Island currently requires accessing 11 state websites.“

Consider that each of the 11 websites constitutes a request on the part of the restaurant. Consider that most of the sites would require an authorized and accountable human to make the each request. Most, if not all, would include:

• the accountable human
• their claims of authority
• the scope of their request (liquor, hours, etc…)
• the reason for the scope of the request
• payment

Also consider how likely it would be for the restaurant to want to outsource some or all of their 11 requests to a lawyer or other delegate.

Adrian

On Thu, Feb 9, 2023 at 4:47 PM Dave Longley @.***> wrote:

@decentralgabe https://github.com/decentralgabe,

You asked me to respond to the options above -- though I do think it's working backwards as I mentioned. I will leave some comments on the options as you asked, but I really do recommend that people look into solving specific use cases first instead of looking at possible problems with possible solutions in the abstract.

Option 1: Single credential, multiple issuers per single issuer identifier

A single conceptual issuer fails with the following considerations:

1. It does not immediately communicate to the holder or recipient(s) of VCs that there are multiple issuers. It requires additional resolution and parsing infrastructure which increases the burden for a credential to be understood.

Why does this need to be communicated at all? Maybe this is a feature, not a bug? This is why specific use cases need to be explored.

1. Not all DID methods support multiple parties to be listed. This would be eliminating a broad class of users for multi-issuer credentials.

You don't have to support this through DID methods. Additionally, mechanisms could be developed that abstract away the details of using any particular key registered with any DID method, including ones that produce static DID docs like did:key. A simple example of this is putting the private key in an HSM that is accessible via WebKMS where access to sign with the key is managed via ZCAPs. More complex examples could be constructed. This is just another example of not exposing the details to verifiers, thereby enabling more existing software to work without any changes.

1. Not all DID methods support historical resolution of DID state. This means that there could be a point-in-time where the DID contained multiple issuers, and that point-in-time could be lost forever. This would make it impossible to know who actually issued the credential and does not at all help further the multi-issuer use case.

This seems orthogonal. Indeed, even if multiple issuers were listed in the same credential, I can imagine ways in which this concern would be unaffected.

Option 2: Multiple credentials, single issuer per credential

This approach fails the requirements for a number of real world use cases by increasing complexity and management overhead. We would need a way to normatively link credentials together, that is, to say that this credential is part of a multi-issuer pair. Complex, and confusing for both holders and verifiers--all interactions with these credentials now become a coordination problem.

We covered this above.

There are two buckets of use cases that we have certainty we need this functionality for:

1. Where you need multiple signatures to authorize the same legal doc / authorization to take action (e.g., Unanimous Withness Consent https://www.wonder.legal/us/modele/action-unanimous-written-consent#:~:text=An%20Action%20by%20Unanimous%20Written,face%2Dto%2Dface%20meeting., Treaties, DAO actions, application for a marriage license, to adopt a child, or any joint resolution).

It seems like the common link here is another agreed upon document that each party could reference in the VC they generated. That same document could list all of the expected signatories. You recommended that this be the particular use case to start chasing down in detail and it's a perfectly good choice.

1. Where you need multiple signatories, but on different parts of a legal doc / different actions authorized by different signatories to unlock some common thing (e.g. signature by an individual and a notary for a home loan or title).

It again seems like different issuers could issue different VCs referencing their sign off on the appropriate parts. In fact, it seems like this would get far more complicated / not be modeled properly if we used "multiple issuers" of the same VC here, but that's just a gut reaction. Again, a good reason that the use cases need to be rigorously explored.

Hopefully this is the response you were looking for. I recommend that people deep dive into the use case you suggested as a way to move the conversation forward around what potential solutions might look like.

— Reply to this email directly, view it on GitHub https://github.com/w3c/vc-data-model/issues/932#issuecomment-1424940349, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABB4YJ3GBG5ZKCZQW7OHXTWWVXYDANCNFSM6AAAAAAQOQ3X5A . You are receiving this because you commented.Message ID: @.***>

[OR13]

Here is a hypothetical use case:

https://www.whitehouse.gov/briefing-room/statements-releases/2022/02/26/joint-statement-on-further-restrictive-economic-measures/

"issuer": [{
  "name": "European Commission",
  "id": "https://press.eu.example/issuers/1"  // example, not an endorsement
},{
  "name": "France",
  "id": "https://press.fr.example/issuers/2"  // example, not an endorsement
},{
  "name": "Germany",
  "id": "did:web:press.de.example"  // example, not an endorsement
},{
  "name": "Italy",
  "id": "did:ethr:..." // example, not an endorsement
},{
  "name": "United Kingdom",
  "id": "did:btcr:..."  // example, not an endorsement
},{
  "name": "Canada",
  "id": "did:indy:..."  // example, not an endorsement
},{
  "name": "United States",
  "id": "did:web:example.gov"  // example, not an endorsement
}]

Would the statements about the subject be more or less meaningful with only 1 issuer?

There are lots of scenarios where issuer's might only feel comfortable making statements about a subject together, a quick google search for "joint statements" reveals a lot of potential use cases...

[OR13]

Example:

https://v.jsld.org/3cy82JzSKePg2ejfikm3oWhpA1t2XHREWbYW7CMCxvCBMrCJx1bjy9peTgn5q7WrEDMwgAHar3sN1timCQBTJ7Rnymdy6NW5xQJuU4TajAUTTkvFrqs9jgPqamvws9cuyQvi2Kj3TybY86LfjqM9dUS2gsoXcwfYyQ7DgjMERgKgMzFm7m7r7sBGdAQt3BBBfP7aQGt7mCBcrqV99zhuPUAX7Cn23Lutkkg2QrCSZBjvpFR6TZ4Mdv8MCzjjPqyb4V9ggtbsp9hdqQkL667ToM3ApxrgKJ

<ddid:example:456> <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <https://www.w3.org/ns/credentials/issuer-dependent#Organization> .
<did:example:123> <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <https://www.w3.org/ns/credentials/issuer-dependent#Organization> .
_:c14n0 <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <https://www.w3.org/2018/credentials#VerifiableCredential> .
_:c14n0 <https://www.w3.org/2018/credentials#credentialSubject> <did:example:789> .
_:c14n0 <https://www.w3.org/2018/credentials#issuer> <ddid:example:456> .
_:c14n0 <https://www.w3.org/2018/credentials#issuer> <did:example:123> .
_:c14n0 <https://www.w3.org/2018/credentials#validFrom> "2023-05-09T22:25:23.652Z"^^<http://www.w3.org/2001/XMLSchema#dateTime> .

Suggest closing, its already supported.

[dlongley]

That's not compact form -- won't work. Not supported.

[iherman]

The issue was discussed in a meeting on 2023-06-06

• no resolutions were taken

View the transcript

#### 1.5. Representing Multi Issuer Credentials in the VCDM (issue vc-data-model#932) _See github issue [vc-data-model#932](https://github.com/w3c/vc-data-model/issues/932)._ **Brent Zundel:** Representing multi-issuer credentials. Question remains, is this something we want to tackle before CR? **Orie Steele:** Similar to multiple subject, all representations and securing mechanisms allow it... I think it can be handled post-CR, if at all. If there aren't strong examples in core spec, by default, not a good thing to be doing, don't think we need to do anything w/ this - close issue, if it remains open, someone should create a good example or issue should be closed. **Brent Zundel:** proposal to mark as pending close, any other comments on issue? > *Orie Steele:* anything is an object if you are brave enough... especially javascript arrays. **Andres Uribe:** To Orie's point, we do have a lot of examples of real life use cases, but not clear how it works... co-tweets, parents claims about their children, co-signers on loan... what examples do we need for this? > *Orie Steele:* I meant a single spec example, with multiple issuers. > *Orie Steele:* the `@context` allows multiple issuers, and that is what is signed over in both representations. **Dave Longley:** Agree with most of what Brent said, but maybe disagree w/ having multiple IDs... what spec says today doesn't allow multiple issuers. Don't think it's actually supported today, if people want a change, that needs to happen before CR. **Brent Zundel:** does this need to change before CR, any volunteers? > *Manu Sporny:* pdl-ASU: Does this involve guardianship, or is that different? **Brent Zundel:** multi-issuer VCs could be one way, but not the only way. > *Orie Steele:* yep, multi issuer and multi subject are both related / required for some scenarios. > *Orie Steele:* but afaik, nobody is using them (either). **Joe Andrieu:** I'd be hard pressed to understand how that would work. **Manu Sporny:** Just to highlight, I don't think that's an issue, Phil. You can always do multi-issuer by issuing multiple VCs. That may be distasteful in some cases but it works. You can have two VCs claiming a child, and so on. … We're covered as far as use cases are concerned, the question is, is that the most ideal form. To be clear, I don't think we need to deal with this in 2.0. > *Dave Longley:* pdl-ASU: Very good. > *Andres Uribe:* +1 for future. **Brent Zundel:** ok, so suggestion that this is not a VC2.0 thing -- do we mark pending close, or mark future? **Joe Andrieu:** Do you want to keep this around, Phil? > *Manu Sporny:* pdl-ASU: I just want to make sure we consider this in v3.0... however we keep it around is good. **Manu Sporny:** I guess the only concern I have with keeping it around is that our issuer tracker ends up collecting a lot of cruft over time. Things that are continuously not addressed. If this is an important enough use case it will be raised again saying they want the spec changed. My preference is to close as many issues as possible if they haven't been worked on. … The WG has been operating since 1.0 and 2+ years since then and no one hasn't worked on it. The history will still be there if we close it. > *Dave Longley:* pdl-ASU: I will check with some people I know doing guardianship and see if they are ok with handling it. **Joe Andrieu:** We would accept use cases in the VC use cases document. > *Manu Sporny:* pdl-ASU: That's a good suggestion, thanks Joe. > *Joe Andrieu:* +1. > *Dave Longley:* +1 to brent. **Brent Zundel:** So, mark this pending close because there is not consensus to do it. Any objections? **Manu Sporny:** +1. **Brent Zundel:** ok, marking pending close.

[decentralgabe]

Closing as there are other ways to address the given use cases.