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)