Closed decentralgabe closed 1 year ago
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?
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.
@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.
The issue was discussed in a meeting on 2023-02-01
@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.
@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.
A single conceptual issuer fails with the following considerations:
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.
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:
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."
@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,
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.
@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:
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).
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.
@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:
- 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.
- 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.
- 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:
- 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.
- 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.
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:
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:
- 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.
- 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.
- 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:
- 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.
- 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: @.***>
Here is a hypothetical use case:
"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...
Example:
<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.
That's not compact form -- won't work. Not supported.
The issue was discussed in a meeting on 2023-06-06
Closing as there are other ways to address the given use cases.
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
Prior Art
Use Cases
What Would It Look Like?
Questions