Remove 3-party Issuer-Holder-Verifier diagram and replace with 2-party Raw Credential Sender-Receiver Model

[mwherman2000]

In the same vein as #999 (review), the "VC Data Model" specification doesn't need to have and shouldn't include the 3-party Issuer-Holder-Verifier diagram in section https://www.w3.org/TR/vc-data-model/#ecosystem-overview .

The flow depicted in this diagram is overly prescriptive and biased. It reflects only one use case: the use of Verifiable Credentials in an Identity Wallet scenario ...which is a small and restrictive use case when one considers the infinite number of ways verifiable credentials can be used in commercial business applications. e.g. https://hyperonomy.files.wordpress.com/2023/01/image-7.png

The diagram should be removed from this version of the specification.

cc: @Sakurann

[TallTed]

The note which immediately follows the diagram you want removed states explicitly that that diagram "provides an example ecosystem in which to ground the rest of the concepts in this specification. Other ecosystems exist, such as protected environments or proprietary systems, where verifiable credentials also provide benefit." which answers your concern as written in your second paragraph above and the ecosystem shown in your linked diagram.

In other words, the diagram in the spec is neither prescriptive nor limiting, and is present only to help readers understand the concepts covered by the rest of the document, which I believe it does. In my opinion, it should be retained.

[mwherman2000]

...and hence, it's not required in a technical specification (i.e. it's supliferous, extra baggage). Your rationale justifies the diagram's removal to a W3C application note or some other vehicle.

[mwherman2000]

The next most likely question is: What do we replace the 3-party model with?
We replace it with only what is necessary and sufficient for a technical specification: a 2-party Sender-Receiver model. This is all the VC2 spec needs/requires. For example, something like...

The topic of application-specific roles like Issuer, Holder, and Verifier needs to be removed to a separate W3C Note (or alternatively, to help minimize the number of changes to VC2 as an interim specification, the following changes to the https://www.w3.org/TR/vc-data-model/#terminology section can be adopted).

In the section https://www.w3.org/TR/vc-data-model/#terminology, the following additions are proposed to the following definitions:

1. holder - Holder is a combined specialization (aggregation) of the Credential Receiver and the Credential Sender roles.
2. issuer - Issuer is a specialization of the Credential Sender role.
3. verifier - Verifier is a specialization of the Credential Receiver role.

Further, the Credential Sender and Credential Receiver roles can be assigned to either an Agent actor or a Wallet actor.

@Sakurann, can Microsoft support these proposed changes in the same vein as the other simplifications Microsoft has also proposed/supported/advocated to the VC2 specification?

[brentzundel]

In my view, the 3 party model introduced in the VC Data Model v1.0 was one of the key innovations of the first WG.
I am opposed to it's removal.

[mwherman2000]

In my view, the 3 party model introduced in the VC Data Model v1.0 was one of the key innovations of the first WG.
I am opposed to it's removal.

@brentzundel Perhaps. ...and I would even agree. However, as I mentioned at the top of this issue, in hindsight, ...

The flow depicted in (Issuer-Holder-Verifier model) diagram is overly prescriptive and biased. It reflects only one use case: the use of Verifiable Credentials in an Identity Wallet scenario ...which is a small and restrictive use case when one considers the infinite number of ways verifiable credentials can be used in commercial business applications.

That being said, I've found a place for the Issuer-Holder-Receiver model as a derviation or specialization of the Layer 3 Verifiable Credential Sender-Receiver Model (which in turn is a derivation or specialization of the Layer 2 Raw Credential Sender-Receiver Model) in the Web 7.0 Trust Spanning Layer Framework (and indirectly in the Web 7.0 Verifiable Credential Architecture Reference Model (VC-ARM)):

• Web 7.0 Trust Spanning Layer Framework 0.57 (https://www.youtube.com/watch?v=rrFfuUHHmr4&list=PLU-rWqHm5p44AsU5GLsc1bHC7P8zolAAf&index=4)

• Web 7.0 Verifiable Credential Architecture Reference Model (VC-ARM) 0.59) (https://www.youtube.com/watch?v=7LpVR0u18s0&list=PLU-rWqHm5p44AsU5GLsc1bHC7P8zolAAf&index=5)

[mwherman2000]

Here's another approach: https://youtu.be/uo4RuT__IXw?t=575s

You may need to watch the following as background:
https://youtu.be/uo4RuT__IXw?t=401s

[OR13]

I suggest closing this, it does not seem like it will gain consensus.

I will object if a PR is raised.

[iherman]

The issue was discussed in a meeting on 2023-04-05

• no resolutions were taken

View the transcript

3.4. Remove 3-party Issuer-Holder-Verifier diagram and replace with 2-party Raw Credential Sender-Receiver Model (issue vc-data-model#1008)

See github issue vc-data-model#1008.

Brent Zundel: Remove 3-party Issuer-Holder-Verifier diagram and replace with 2-party Raw Credential Sender-Receiver Model.

Dave Longley: I would also recommend we close this.

Oliver Terbu: +1 closing this issue.

Sten Reijers: +1 to close this.

Michael Jones: Once again, I agree that three-party model is integral to what we've created and how it's used. This should closed with prejudice.

Brent Zundel: There is no consensus in the group to change the three-party issuer-holder-verifier setup.
… Therefore we are going to close this.,.
… We will include in the weekly communication the list of issues that are marked "pending close".
… We're not necessarily going to say in a call that we want to close it.

[brentzundel]

No objections raised since being marked pending close, closing.