Representing Multi Issuer Credentials in the VCDM #932
Comments
|
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:
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. |
|
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. |
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:
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.
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. |
|
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. |
https://www.rfc-editor.org/rfc/rfc7515#appendix-A.6.4 Notice the missing Is JWS multisignature well supported today? What are some pitfalls? Is there a compact serialization? |
|
Here is part of the answer from the test vectors RFC: https://www.rfc-editor.org/rfc/rfc7520#section-4.8
^ This would require a normative text change.... and probably the ability to do something like |
|
@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. |
|
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. |
|
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. |
+1 to the need for clearer language. -1 to expressing additional possibilities without first having proper criteria for determining what does (not) qualify as a holder/subject/prover/issuer/verifier/validator/..., at least for use within the context of VCDM, which (for me) implies that all (active) stakeholders for the VCDM have demonstrated they have the same understanding of such terms. |
|
This is where I find cognitive dissonance with the VCDM based on Triples. The exchange of VC is an information exchange. It is a transaction. Transactions have their own properties. The roles of the exchangers does not necessarily have anything to do with the information being exchanged. Or at the very least there is a narrow set of information that is needed to support the exchange of OTHER information as payload to the exchange that may be perfectly opaque to the exchange process itself. When the other information and the information needed to support the exchange are confused then we have this cognitive dissonance. This does not mean that a link between the exchange supporting information and the information in the exchange’s payload is ruled out. But only in some exchanges and only by virtue of shared identifiers. The same identifier can play a role a primary identifier to the exchange and also be referenced in the payload for some other role that is independent of the role in the exchange. This makes it easy to define roles. The confusion of the terms holder/subject/issuer/… is a result of confusing the roles that support an exchange protocol with the roles of some higher level payload. One good reason to have a VCWG2 is to create a true separation of concerns. The VCDM needs to decide. Is it about an exchange protocol (issuance, presentation, disclosure, terms of use, authentication, authorization, confidentiality , privacy of that exchange) and about the roles the parties to the exchange play or is it updating a distributed database which update is an opaque payload of that exchange. The latter is a more appropriate match to triples where semantic web constructs play, although other data models besides triples work as well. The former does not benefit from semantic web constructs, indeed they only complicate it. |
|
Presentation is confusing because it has a vague relationship to the
transaction that the presentation is a part of. The context is the
transaction, not the presentation.
I can imagine reasons why the issuer might want to limit the transaction
contexts, but even then I’m not sure presentation is a useful concept.
Consider the example of gov wanting to limit the use of SSN or Aadhaar to
gov transactions. How would specifying that in the VC context actually
enforce the unintended use by a verifier?
The context for a VC should be just about the VC proof. How it’s used in a
transaction should be entirely up to the context of the transaction. What
am I missing?
Adrian
…On Mon, Oct 3, 2022 at 10:18 AM Samuel Smith ***@***.***> wrote:
This is where I find cognitive dissonance with the VCDM based on Triples.
The exchange of VC is an information exchange. It is a transaction.
Transactions have their own properties. The roles of the exchangers does
not necessarily have anything to do with the information being exchanged.
Or at the very least there is a narrow set of information that is needed to
support the exchange of OTHER information as payload to the exchange that
may be perfectly opaque to the exchange process itself. When the other
information and the information needed to support the exchange are confused
then we have this cognitive dissonance. This does not mean that a link
between the exchange supporting information and the information in the
exchange’s payload is ruled out. But only in some exchanges and only by
virtue of shared identifiers. The same identifier can play a role a primary
identifier to the exchange and also be referenced in the payload for some
other role that is independent of the role in the exchange. This makes it
easy to define roles. The confusion of the terms holder/subject/issuer/… is
a result of confusing and roles that support an exchange protocol with the
roles of some higher level payload.
—
Reply to this email directly, view it on GitHub
<#932 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AABB4YN7SXSCCL7KY5GUPA3WBLTJTANCNFSM6AAAAAAQOQ3X5A>
.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
|
|
What is the VC proof proving? Is it proof of issuance? Is it proof of Authorization by an issuer to and issuee. Is the proof related to a type of disclosure such as selective disclosure. Is is a range proof? Is is a herd privacy proof. The type of proof is entirely transactional. And that's my point. The VC data model is confused because proofs are part of transactions/interations between a prover and a provee not a distributed database in the sky that is semantic. Proofs are highly contextual because of they require a relationship between the parties engaged in the proof. |
|
If we only allowed one type of proof, that is a proof of issuance with only an Issuer and no Issuee, then we could frame it as a non-interactive non-transactional proof. But the majority of use cases for Credentials (which by definition, a credential is evidence of entitlement), mean that there is an Entitler and Entitlee i.e. a transactional relationship and that's where the semantic web runs aground because it is not meant to be transactional. We need a lower layer that is transactional, where all the proofs and associated transactions, the IDs related to the parties engaged in those transactions along with roles defined by the type of transaction all reside. And then we need a higher layer that is an opaque payload to this transactional layer. Then we will have clean separation of concerns and all the ambiguity we have been discussing for the last 4 years goes away. We will have extreme clarity. I call this transactional layer the A4 layer for Authored, Authenticated, Authorized, Authoritative. Any data that needs to be exchanged in a secure trustworthy way needs some or all of the 4 A's. These form the minimally sufficient means. This A4 exchange layer can be augmented with optional confidentiality and privacy preserving exchange mechanisms. So this A4, Confidentiality, and Privacy exchange layer becomes the trust spanning layer and then semantic data can be delivered in a trustworthy way simply as a payload of the exchange layer. This makes the semantic layer simple and makes the exchange layer simple. Mixing those two layers is complex because they are incompatible. One is transactional, cryptographic, with narrow semantics the other is well broadly semantic but non-transactional and non-cryptographic. |
|
As a caveat, lest my use of the term semantic devolve into a discussion of what a semantic is. To be clear transactions themselves have semantics, they have models. But the models are narrowly defined and constrained by the transaction. They are not the open world semantic model that the semantic web in general is trying to realize. And that is the cognative dissonance. Trying to stuff an open world data model into the very narrow closed world of A4, confidentiality, privacy exchange transactions. |
|
It seems to me that the VCWG2 is an opportunity to fix this unfortunate confusion of concerns and clearly delineate athe narrow semantics of an exchange layer from the broad semantics of a payload of the exchange layer. Maybe this splits the WG into two WGs once for doing all the A4, Confidentiality, Privacy exchange modeling and the other doing the payload modeling. |
|
So for example. If I have only the need to provide a proof of issuance, then an authenticated key pair linked to an Issuer identifier that may or may not be linked to a natural persor or legal entity along with a non-repudiable digital signature made with that key pair provides a conceptually clean model for proof of issuance. But as soon as I attempt to make that data for which I can prove issuance into an entitlement then I have two parties. The entitler and the entitlee. Each with a keypair and identifier with possibly links to natural persons and legal entities. Now I have to answer the question, what role does the entitlee play, in a given transaction is it the holder, the issuee, the discloser in a presentation of the credential to some other party. Oh wait what is the other party now. We have three parties. Could we have more parties. Yes of course. We could have a credential issued by an Entitler to and Entitlee that is held by some other party and that other party could actually be the discloser fo the credential to yet another party. How is this disclosing party related to the entitlee. Is is a proxy. is is a custodian, is it and agent? These are all transactional roles that have little to do with the payload of the entitlement itself and everything todo with the type of transaction involved in the exchange of the entitlement. So we its not clear what a holder is, then it is clear that we have a confusion of concerns between the transactional exchange layer where the roles are clearly defined by the type of transaction and the payload layer that may or may not reference data related to the parties engaged in the transaction but should in all cases be opaque to the semantics of the transaction other wise its not a payload. This is how layered protocols are meant to work. |
|
A set of transactions that are exchanges can be used to build a complex model of relationships. One transactions can carry a payload of data that can later be referenced in support of some other transaction. The later transaction has clear semantics of the parties and roles to the transaction as defined by the transaction type. But either party may reference payloads of prior transactions in order to make decisions about a later transaction. This is how reputation works. The temptation is to flatten the layers, and that is a temptation that should be resisted. Collapsing layers increases complexity not decreases complexity. Complex systems are in general best understood as hierarchical compositions of information that functions best at a given layer in that hierarchy. There are applications where flattening layers can reduce complexity, but this is not one of them. Maybe that is the crux of the disaggreement. We have one camp that wants to flatten all information and information exchange into one semantic web construct and the other camp (to which I belong) that thinks this is a bad idea. |
|
@SmithSamuelM "So for example. If I have only the need to provide a proof of issuance," |
|
@SmithSamuelM — It's hard to digest and respond properly to your walls of text, especially with incorrect punctuation (such as many periods where question marks belong) and frequent typos (such as instances of I expect these challenges are much greater for the many folks working on this for whom English is a second or later language. Please take some time to read over your last several comments, and correct as much as possible. Breaking up your larger streams of text into more consumable paragraphs will also help a lot. I'm sure that every minute you spend doing this will save (at least!) several minutes for your readers, certainly in aggregate and likely for each individual reader, who otherwise have to each spend time trying to figure out what you meant through the typos, etc. |
|
CONCRETE PROPOSAL Add the new role of issuee to the V2 data model, which the issuer can optionally insert into the issued VC. The structure of issuee is alligned to be the same as issuer (i.e. object or string). |
|
@TallTed Sorry for the typos. I will be more careful. @David-Chadwick I believe that this is precisely the problem of ambiguity between holder/subject/... discussed above. Is the Issuee identifier counted as meta-data? If the identifier of a party to the transaction is not meta-data then how does it fit into the VCDM. Clearly, any identifier can be represented as an object/string as metadata, but how does that object/string identifier fit into the subject/object/predicate model of the VCDM. We could represent every party associated with a transaction as metadata, and that would be just fine. Indeed, that is effectively what I am proposing. Because then this set of metadata can be used in its own transaction layer that supports a higher non-metadata layer. |
|
@SmithSamuelM The reason for introducing the new role of issuee is to remove all ambiguity between subject and holder.
Once the VC has been issued it may pass from the issuee to no-one, or to the subject, or to a third party. Whoever it passes to (including no-one) is the holder of the VC until it is passed on again. It could of course be duplicated and passed to multiple holders. The holder is never identified in a VC because the VC is persistent and the holder is not. |
(First, note the typo, " Why change your phrasing for this, instead of following the same form as the first two, i.e., " (I would suggest also changing both instances of |
|
I'd like to propose a PR that captures the following:
Please 👍 👎 if you would be supportive of such a PR. |
|
+1 as long as it is clear that "There can be multiple methods of securing multi-issuer credentials" and each method will be defined in each securing spec |
|
My thumbs down above is because I don't think we're quite ready to say that expressing multiple issues in the same VC is the best way forward. There are some other approaches that have been mentioned for solving the use cases, and, I usually find that keeping primitives simpler, so long as they can be combined to solve more complex use cases, is a better design (for basic understanding, implementation complexity, security, etc.). |
-0.7 on a PR that captures all of that, but only due to concerns regarding ecosystem complexity, more below:
The makes the ecosystem more complicated for a limited return on that complexity. It's not clear that the extra use cases justify the added complexity.
+1 to the above.
Yes, and this is where the concern comes in. The more options we have here, the more implementation complexity there will be. The question is: Can we achieve this multi-issuer use case by using the primitives we have today, such as a collection of VCs that say the same thing issued by different issuers?
We could achieve the use case using a single issuer w/ a multisig scheme... that would re-use primitives we have today w/o adding the complexity of updating the
We could achieve the use case with a single issuer field today by taking this approach.
We could achieve the use case with a single issuer field today by adding the 'content addressing other VCs' proposal that @dmitrizagidulin and @longpd put together.
We could achieve the use case with a single issuer field today by doing this.
We could achieve the use case with a single issuer field today by doing this. All this to say, we could keep the issuer field as a single value and do all of the things above to add issuers... OR, we could expand the issuer field to reference multiple issuers BUT, if we do that, we really should settle on (ideally) one of the mechanisms above. If we don't do that, it feels like we're begging for interop failures... or massive ecosystem complexity. I don't think it would be an easy ask of our engineering team to implement 6 different security schemes for the "multiple issuers" use case. If we can focus on one mechanism, that would be a much easier ask (but I understand that it'll take work to get there). |
|
I don't really have an opinion on this, but regarding:
I wanted to point people to this proposed verification method, which I think is really interesting: |
|
@msporny @dlongley I think (correct me if I'm wrong) I find your posts self-contradictory. You are saying yes we do support multi issuer credentials, but with what we have today. And what we have today is not multi issuer credentials - meaning they're not allowed at all. I'd like to distinguish here between the concept of "multiple issuers" and "there are multiple values for the Manu, you're correct that many but not all multi-issuer schemes can leverage a single issuer field and that's a good thing, and an argument in favor of updating language to allow for multi-issuer credentials. The first spec text change would be to say multi issuer credentials are allowed and one way (and maybe the only one that reaches consensus) of doing this is using the security mechanisms we have today. I would recommend my first PR does update the issuer field to allow multiple values because there are cases where multiple issuers can be represented by a single signature, as in the case of multi-sig schemes like schnorr. I would next recommend adding language about the possibility of supporting multiple signatures on a single credential, but this will be more controversial. So, two PRs, possibly three for easier consensus (1 & 2 can be combined):
I agree having a concrete mechanism may help. I think getting 1 and hopefully 2 in first can make that easier. |
|
For schemes where multiple issuers are actually multiple parties operating as a single conceptual issuer, I would expect this single conceptual issuer to be indicated at the data model level, with further details within the proofing mechanism on which issuers had contributed to the proof and how. Having such multi-issuer support would be out of scope of the VCDM, but might affect other in-scope proofing mechanisms. However, for multiple independent issuers to be represented at the data model layer, I would expect these to be multiple parties making the exact same statement with the exact same conditions - e.g. they are both asserting every predicate of the subject equally, are requiring the same expiry times, utilizing the same evidence, and so on. Assuming a proof mechanism that meets the needs of an issuer which is a composite of multiple parties, is there a use case which mandates these constituents be represented as multiple issuers at the credential level, rather than a single composite issuer and a proof that explains who and how the credential was secured? I would assume having this information within the proofing mechanism is far more appropriate, as it already would need to represent multiple independent proofs or describe parameters needed by the threshold scheme, associated with those constituent issuers. Likewise, I would assume the many permutations being represented by a common conceptual issuer would be needed, as someone needs to give common recommendations for verifiers on what is sufficient for verifiability and validation, and arrange for those issuers to be able to coordinate common data requirements to make such identical assertions about the credential subject(s) |
|
@dwaite +1 |
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. Again, I believe securing the data model is a separate concern than representing statements about credentials in the data model itself, of which, having multiple issuers is one such statement. |
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 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? |
it would make sense to define a credentialStatus property that has multi-issuer support. that's what extensibility is all about!
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. |
|
I think the problem here is that it seems insufficient to just modify the 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 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
View the transcript4.1. Representing Multi Issuer Credentials in the VCDM (issue vc-data-model#932)See github issue vc-data-model#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..
Kristina Yasuda: We discussed mechanisms such as chaining, I think GS1 has something in production with multiple issuers.. 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..
Dmitri Zagidulin: I agree that multiple issuers is a legitimate use case.. Kevin Dean: The GS1 example is not one of multiple issuers in this sense.
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..
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..
Kevin Dean: For treaties, certain contracts, there may well be requirements for multple issuers in low trust environments..
Orie Steele: I agree with what KevinDeanGS1 said and what decentralgabe said initially.
Orie Steele: Going back to what decentralgabe said, the data model is about the intention, and securing it is a separate concern..
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?.
Dmitri Zagidulin: I think there would be great value if we restrict a VC to a single issuer..
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..
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.
Kristina Yasuda: I encourage continued conversation about the data model aspect of this..
Kristina Yasuda: Thank you everyone, see you next week.. |
|
@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. |
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 identifierA 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. Option 2: Multiple credentials, single issuer per credentialThis 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:
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.
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." |
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. |
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. |
|
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.
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.
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
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.
We covered this above.
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.
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:
- 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
<#932 (comment)>,
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: 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
View the transcript1.5. Representing Multi Issuer Credentials in the VCDM (issue vc-data-model#932)See github issue vc-data-model#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?
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?
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?
Brent Zundel: multi-issuer VCs could be one way, but not the only way.
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.
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: 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.
Joe Andrieu: We would accept use cases in the VC use cases document.
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. |
|
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
The text was updated successfully, but these errors were encountered: