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?

[decentralgabe]

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

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

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

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

[RieksJ]

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

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

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

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

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

[decentralgabe]

@RieksJ

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

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

To be valid a verifier must receive authorization from:

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

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

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

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

[David-Chadwick]

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

[OR13]

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

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

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

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

[OR13]

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

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

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

[SmithSamuelM]

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

[decentralgabe]

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

[SmithSamuelM]

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

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

[RieksJ]

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

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

To be valid a verifier must receive authorization from:

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

+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.

[SmithSamuelM]

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.

[agropper]

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 https://github.com/w3c/vc-data-model/issues/932#issuecomment-1265513112, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABB4YN7SXSCCL7KY5GUPA3WBLTJTANCNFSM6AAAAAAQOQ3X5A . You are receiving this because you are subscribed to this thread.Message ID: @.***>

[SmithSamuelM]

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.

[SmithSamuelM]

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.

[SmithSamuelM]

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.

[SmithSamuelM]

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.

[SmithSamuelM]

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.

[SmithSamuelM]

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.

[David-Chadwick]

@SmithSamuelM "So for example. If I have only the need to provide a proof of issuance," But what if I have the need to provide proof of issuance to a specific entity? Then in that case the issuer would include the public key of the entity in the issued credential. This is still a clean model. There are still only two parties involved. The issuer and the issuee. But what if I need to provide proof of issuance that the credential is about a specific entity. Then in that case the issuer would include the public key of the credential subject. This is still a clean model as only two parties are involved. And if I need to provide proof of issuance to a specific entity that the credential is about a third party, then the credential would include the public keys of the subject, the issuer and the issuee. I see nothing wrong with having all of these requirements modelled in the VC DM v2. They are all independent of what happens next to the credential after it has been issued.

[TallTed]

@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 is is that should be is it).

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.

[David-Chadwick]

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).

[SmithSamuelM]

@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.

[David-Chadwick]

@SmithSamuelM The reason for introducing the new role of issuee is to remove all ambiguity between subject and holder. So,

1. the issuer issues the VC to the issuee (always) and may optionally insert the latter's identity into the VC.
2. The issuer inserts its own identity into the VC it issues (always)
3. The issuer issues the VC about a subject (always) and may of may not uniquely identify the subject.

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.

[TallTed]

[@David-Chadwick] 3. The issuer issues the VC about a subject (always) and may of [sic] may not uniquely identify the subject

(First, note the typo, "may of" should be "may or".)

Why change your phrasing for this, instead of following the same form as the first two, i.e., "3. The issuer issues the VC about a subject (always) and may optionally insert the latter's identity into the VC"?

(I would suggest also changing both instances of the latter's to be explicit, i.e., the issuee's in (1) and the subject's in (3), in your framing. I would also suggest being explicit with about one or more subjects, as leaving this out may take us down another rabbit hole where "subject must be singular!")

[David-Chadwick]

Thanks Ted for correcting my typos. So how about:

1. The issuer issues the VC to the issuee (always) and may optionally insert the issuee's identity into the VC.
2. The issuer inserts its own identity into the VC it issues (always)
3. The issuer issues the VC about one or more subjects (always) and may optionally insert the subject's (or subjects') identity into the VC.

[TallTed]

I suppose we should also support the possibility of multiple issuees (think, carbon copies) for a single VC...

And we should always differentiate between "identity" and "identifier".

1. The issuer always inserts its own identifier into any VC it issues.

2. The issuer always issues a VC to one or more issuees, and optionally inserts the issuee identifier(s) into the VC.

3. The issuer always issues a VC about one or more subjects, and optionally inserts the subject identifier(s) into the VC.

[decentralgabe]

@David-Chadwick I like your suggestion of issuee, I can see it clearing up confusion. Related to #931 it could be "issuees" if applicable as you and @TallTed both mention.

So, now we have issuer and issuers, and issuee and issuees. I'd like to get a PR going to encapsulate these changes but could use some assistance. Is anyone willing to pair with me to get a well-thought out change drafted?

[David-Chadwick]

I was going to produce a PR if my suggestion was positively received. So happy to work with you on this

[TallTed]

I think it's time to move the issuee discussion to its own issue, as it isn't necessary to any (though it has relation to all) of #930, #931, nor #932.

[SmithSamuelM]

@TallTed +1
@David-Chadwick +1

CONCRETE PROPOSAL

+1 to Issuee(s)

[Sakurann]

(probably a topic for another coming issue), but -1 to a term issuee (not necessarily the concept). from a non-native speaker perspective, the term is not exactly intuitive and confusing.

[David-Chadwick]

Holder binding is conceptually different to issuee binding because the role of holder is conceptually different to the role of issuee. The former is not fixed as holders can change from day to day. The issuee never changes, ever. So the issuer can bind a VC to an issuee, but never to "the holder" as the holder is whoever it happens to be at any point in time. So a subset of the techniques of the holder binding work can be used for issuee binding

[dwaite]

My concern is that a single property will not be robust enough. In particular, issuees tend to have their own properties - including the relationships with the subject(s) and issuer(s?), and any additional information needed for them to do a presentation proof. In some cases, the issuer may even try to convey whether or not that party is expected to issue statements about another party having a relationship to the original subject(s) or credential.

Since a credential can have multiple statements about different subjects, would it instead make sense to describe an issuee as another subject in a single credential, or possibly via a second credential?

[TallTed]

@msporny @dwaite @David-Chadwick @Sakurann — Please take your latest issuee-related comments to #942 (and hide them here) as this #932 is about multiple issuers, not about issuee. I should have done the same, sooner. :-/

[RieksJ]

@SmithSamuelM wrote

This is where I find cognitive dissonance with the VCDM based on Triples. The exchange of VC is an information exchange.

I disagree. The exchange of VC is a data exchange, where the data represents information of the author, according to the mapping (semantics) that the author uses for that. No two mappings/semantics are the same.

So here is an ambiguity issue related to the meaning of a signature. My understanding of a VC-signature is that the author says: these triples represent some knowledge that I have and that I consider to be true and trustworthy. If there are two signatures that have this meaning, it would imply that both parties would claim to have the identical knowledge, which, if you would argue that could happen, is very dangerous as it is difficult, if not impossible for third parties to establish.

Signatures on checques, contracts etc. have a different meaning. They state a commitment of the signer to abide by, support, etc. the contents of the data that it signs, in the meaning of the author of that document. And of course we need those. But they differ from a VC signature

[SmithSamuelM]

I am not sure I capture the meaningful difference between "an information exchange" and a "data exchange that represents information". ;)

In a layered protocol, the purpose of each layer is to isolate and encapsulate the information essential to the function of that layer. This enables the separation of concerns and avoids the leakage of information. The latter is an essential property of security (authenticity, confidentiality, and privacy) functionality. In a protocol stack there is a hierarchy of layers, where lower layers support higher layers. The higher layer may have visibility down into lower layers, but lower layers do not or should not have visibility into higher layers (the latter would break the encapsulation and leak information). So finally, once the data has climbed the protocol stack, one could then after the fact, flatten the layers (because the topmost layer may have visibility into all the lower layers) and represent the flattened information is one construct, such as a bag of triples. But I strongly suggest that doing so a priori and assuming that such a flattening does away with the need for a protocol stack of encapsulated layers in the first place is a dangerous equivocation.

[SmithSamuelM]

So here is an ambiguity issue related to the meaning of a signature. My understanding of a VC-signature is that the author says: these triples represent some knowledge that I have and that I consider to be true and trustworthy. If there are two signatures that have this meaning, it would imply that both parties would claim to have the identical knowledge, which, if you would argue that could happen, is very dangerous as it is difficult, if not impossible for third parties to establish.

Exactly why we should not be mixing the layers, which your example does.

[SmithSamuelM]

Each Issuer should be empowered to define what a proof-of-issuance attributable to that Issuer means for a given issuance. This must be entirely contextualized to that issuance. The data model of the protocol stack must then have a mechanism that enables the Issuer to express that definition in an interoperable way that enables verifiers to correctly evaluate the proof of issuance. Multiple signatures applied to one issuance could mean something entirely different when applied to another issuance. Consequently, IMHO, this means that each VC must have a type and that type is constrained by the Issuer to mean what the Issuer intends it to mean.

In ACDC type-is-schema. Each schema is immutable. Each schema is identified by a universally unique content-addressable identifier (a hash of the schema). This allows a permissionless registry of schema which define ACDC types. This enables the creator of an ACDC type to publish the rules of the road, so to speak, regarding the interpretation of what a proof-of-issuance conveys to any validator without ambiguity for each type so published. These rules could be embedded in the schema.

By providing such a mechanism, the ACDC spec avoids having to define general universal semantics. It only needs to define the narrow semantics of universal syntactical elements common to all ACDCs. It may avoid defining all the semantics of specific use cases for ACDCs, which are more properly conveyed by the typing mechanism.

So a proof-of-issuance can be verified as proven but what that means from a business logic perspective is up to the Issuer as governed by the type of ACDC the Issuer chose to issue.

Likewise, a chain of ACDCs where each ACDC targets an Issuee identifier defines a chain of Issuer to Issuer to Issuer and so forth ... can be verified as intact or unbroken. The state of the chain (broken or not) is all that ACDCs needs to provide. What such an unbroken chain means from a business logic perspective is entirely up to the ecosystem rules defined for the types of ACDCs included in such a chain. For example, a type of delegation of authority might be the business logic of such a chain). What type of authority is defined by the types of ACDCs employed in the chain. And the Issuer of the origin ACDC (in a directed graph the last added vertex is the origin since the links point backwards) gets to choose what type of ACDC it wants to append to the chain. Which then defines what the proof-of-issuance means.

The recommended approach is to provide an Ecosystem Governance Framework with documents that define the meaning. Everyone who interacts in the ecosystem uses the ACDC types defined for that ecosystem in an ecosystem-wide interoperable unambiguous way.

[SmithSamuelM]

So far with ACDC we only have identified the need for only four roles. All the use cases we can think of are covered by those four roles because the typing system enables the semantics of the roles as used by a given ACDC to be adapted to the use case.

The four roles are:

ACDC Issuer ACDC Issuee (the Issuee is optional and reflects a target identifier of an issuance. Not all issuances need a target identifier)

In the disclosure exchange protocol for an ACDC there are two roles

Discloser Disclosee (The disclosee is optional, a public broadcast disclosure may not benefit from a targeted disclosee identifier)

Too represent multiple Issuers there are two mechanisms.

1) The Issuer identifier is controlled by a multi-sig thresholded group of identifiers. Each member of the group contributes one or more signing key pairs to the muti-sig group. Proof-of-issuance requires a threshold satisfying set of signatures from the multi-sig group.

2) Mutiple Issuers are defined by a set of independent ACDCs, each with a unique Issuer that are chained together to represent a group issuance as a tree. The origin of the tree is an ACDC that links back to the other independent ACDCs. The linked ACDCs each have a different issuer but all have the same Issuee and the same attributes. A verifier can see that all the independent Issuers made a verifiable commitment to the same attributes and Issuee. The origin ACDC in the graph is Issued by the Issuee of the other independent ACDCs. This Issuer to Issuee to Issuer chain provides a verifiable set of multiple Issuers using a tree graph.

These two mechanisms mean we don't have a need to define a single ACDC with a list of Issuers. All ACDCs need to have but one Issuer identifier. Given the multi-sig and/or tree chaining, we can still securely convey the semantics and business logic of any multiple issuer application.

[RieksJ]

Reading through this thread increasingly resembles me walking into a swamp: lots of good points are being made, but I have no clue as to their cohesion. There's a topic on (the meaning) of proofs/signatures - very valid, should be clarified (e.g. as in pk-certs). There's a topic on transactions (exchanging messages the meaning of which is to a considerable extent implied by the transaction context) - we need this as it links to business applications. There's a topic on issuees (and other 'roles' (whatever that means)).

It seems as if we're all playing in a field, but it isn't clear where the field begins, ends, and what the game actually is about. My suggestion is to sit back and think a bit better about what we're actually trying to do here.

My current thoughts on demarcating the playing field is that a VC is meta-data, claims, and proofs/signatures (P/S's), where:

• all claims originate from (the knowledge of) a single party, and there is one signature over the entire VC that has been created on behalf of that party that attests to this (which I call 'issuer' in this post). The semantics (meaning) of the claims originate from that party, who therefore must somehow publish this semantics, or refer to some published semantics (e.g.: a scheme). VCDM will specify what claims may look like in terms of structure/syntax, but any semantics are outside the scope of VCDM (as the semantics is (to be) controlled by the issuer of the VC.
• any other P/S can either be part of a claim, in which case they are out of scope of the VCDM (and must be specified by the issuer of that claim), or of the VC itself, in which case it is in scope of the VCDM, and its meaning must be explicitly specified. I support the argument that a particular (semantic) kind of P/S be only taken in consideration for inclusion in the VCDM if the purpose that it serves cannot be realized in another realistic fashion, e.g. by including it as part of a claim. What constitutes 'realistic' is up for debate; it may include operational/performance arguments, as well as business/policy/governance arguments.
• similarly, any meta-data should be (re)considered along these lines of reasoning. It would make, e.g., an issuingdate part of the meta-data, but expiration date would be disputable. And in the end, it's what the majority of us agree on.

[theblockstalk]

We have built a multi-signature and delegated signature Verification module for verifiable credentials. This supports composable multi-party signatures through a combination of conditional signature Validation requirements expressed in a DID Document using the Conditional Proof verification method.

For this use case, you could create a new DAO-like account on the decentralised data registry, with a DID Document that expresses the need for e.g. 6 out of 8 other DIDs representing countries ( through a delegated account link ) to need to sign to create a valid signature.

We have just finished creating an implementation that works with the did-jwt(-vc) libraries and is DID, VC and JWT standards compliant.

Please read this blog article for information on how this works, and with links to the software. https://blog.tonomy.foundation/verifiable-credentials-with-provable-delegated-and-multi-sig-signatures-e46ca74d7d87

[decentralgabe]

I'd like to propose a PR that captures the following:

• Multi-issuer credentials are supported by the VCDM
• Securing the data model is a separate concern from the language in the VCDM
• There can be multiple methods of securing multi-issuer credentials, such as:
  • multisig schemes (multiple signatures combined into a single signature)
  • wrapping credentials in credentials
  • chaining credentials (i.e. you issued x so now I can issue y)
  • multiple signatures over a single VC
  • a single issuer DID controlled by multiple parties

Please 👍 👎 if you would be supportive of such a PR.

[Sakurann]

+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

[dlongley]

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.).

[msporny]

I'd like to propose a PR that captures the following:

-0.7 on a PR that captures all of that, but only due to concerns regarding ecosystem complexity, more below:

• Multi-issuer credentials are supported by the VCDM

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.

• Securing the data model is a separate concern from the language in the VCDM

+1 to the above.

• There can be multiple methods of securing multi-issuer credentials, such as:

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?

• multisig schemes (multiple signatures combined into a single signature)

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 issuer field.

• wrapping credentials in credentials

We could achieve the use case with a single issuer field today by taking this approach.

• chaining credentials (i.e. you issued x so now I can issue y)

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.

• multiple signatures over a single VC

We could achieve the use case with a single issuer field today by doing this.

• a single issuer DID controlled by multiple parties

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).

[peacekeeper]

I don't really have an opinion on this, but regarding:

• a single issuer DID controlled by multiple parties

I wanted to point people to this proposed verification method, which I think is really interesting: https://w3c-ccg.github.io/verifiable-conditions/

[decentralgabe]

@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 issuer property". It seems we agree on the former but not quite the latter yet.

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):

1. Multiple issuers are allowed with a single issuer value

2. Multiple issuers are allowed with multiple issuer values

3. Multiple issuer are allowed with a variety of signature constructs (as listed above)

I agree having a concrete mechanism may help. I think getting 1 and hopefully 2 in first can make that easier.

[dwaite]

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)

[SmithSamuelM]

@dwaite +1

[decentralgabe]

@dwaite

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?

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.