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

[mwherman2000]

Is the plan for the 3-party Issuer-Holder-Verifier credential exchange diagram going to remain in the TAS documentation? If so, read on...

The TAS specification doesn't need to have and shouldn't include the 3-party Issuer-Holder-Verifier diagram in the document. The flow depicted in this diagram is overly prescriptive and biased. It reflects only one restrictive 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.

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 Raw Credential Sender-Receiver Model. This is all the TAS spec needs/requires. For example, something like...

UPDATE: Important tweaks have been made to the above diagram.

The topic of application-specific roles like Issuer, Holder, and Verifier needs to be removed to a separate application note or alternatively, to help minimize the number of changes to TAS specification, the following changes to the Terminology section can be adopted.

In any Terminology sections, the following additions are proposed to the following definitions:

holder - Holder is a combined specialization (aggregation) of the Credential Receiver and the Credential Sender roles. issuer - Issuer is a specialization of the Credential Sender role. 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.

[darrellodonnell]

@mwherman2000 Until we get IPR issues aligned I think we need to avoid looking at items that are under different / non-compatible IP regimes. While the input is valuable if it is not compatible with the IPR structures that we operate under I think it may put us off base.

[mwherman2000]

@mwherman2000 Until we get IPR issues aligned I think we need to avoid looking at items that are under different / non-compatible IP regimes. While the input is valuable if it is not compatible with the IPR structures that we operate under I think it may put us off base.

The issue may have gotten contorted @darrellodonnell. I had to refresh my knowledge of the TOIP LF Charter and the historical issue related to incorporating the Sovrin Glossary content into the TOIP Glossary.

1. There is nothing actually restrictive in Paragraph 7 of the TOIP LF Charter. (NOTE: It was impossible to find the final approved version of the charter - so I'm referencing this draft version: https://wiki.trustoverip.org/display/HOME/2021-03-10+Steering+Committee+Meeting+Page?preview=%2F74019%2F74026%2FExhibit+C+-+Version+5.0+JDF+Project+Charter+and+Working+Group+Charter.docx).

7. Conditions for Contributions. A Steering Member, General Member, or Contributor may not make any Contribution unless that Steering Member, General Member or Contributor is the exclusive copyright owner of the Contribution or has sufficient copyright rights from the copyright owners to make the Contribution under the terms of this Project Charter and applicable Working Group Charter. The Steering Member, General Member, or Contributor must disclose the identities of all known copyright owners in the Contribution.

I/We meet all of the requirements of Paragraph 7.

2. The core issue relates to the copyright TOIP uses for each specific TOIP document and whether the copyright framework chosen by TOIP protects authors and other contributors who use the Creative Commons Attribution-ShareAlike 4.0 International Public License (https://creativecommons.org/licenses/by-sa/4.0/legalcode). In the case of the Sovrin Glossary scenario, the copyright on the TOIP Glossary wasn't sufficient to protect the Sovrin Foundation and its copyright on the Sovrin Glossary and its content.

So the ultimate question is: What has TOIP (Steering Committee?) chosen as its documented and approved copyright statement for its documents, in general - as well as, more specifically, for the TOIP TAS and TOIP TSL documents (where I'm most likely to be making contributions)?

If this doesn't work out, I'm totally OK with that version of the situation but it's not my first choice ...off to drink coffee overlooking Chelem and Meridia. ;-)

Let's pick something that is friendly toward the G.U.T and the G.U.C initiatives.

...back to you @darrellodonnell ...

CC: @dhh1128

[darrellodonnell]

Answering questions about the IP conditions that ToIP operates under is beyond what I can do.

@JFleenor can you help or find help here?

[dhh1128]

I think the 2-party view and the 3-party view are in some senses variants of one another. Both show the same basic interaction (holder->verifier or sender->receiver), which is the sharing of verifiable data that's at the core of trust-building interactions with credentials. They differ in how much they emphasize upstream issuance and how much they emphasize cross-checking during validation.

In the 2-party view, how a credential came to exist is considered tangential rather than central. It could have been created by the sender, just in time for sending, or it could have been created long before, by an issuer. Since either could be true, leaving the issuer out of scope feels reasonable in this view. And that sets up the other simplification, which is that in the 2-party view, how a credential is validated (note my carefully chosen word here; I didn't say "verified" meaning just a signature check) is also considered tangential. Possibly, the credential requires nothing other than interaction with the sender, because it contains only self-asserted claims. Or possibly, the credential requires lookup of reference data (e.g., public keys, schemas, etc) from a VDR. Because either could be true, the 2-party view leaves them out of scope.

I agree that how a credential came to be (issuance) and how it is validated are both questions that have variableness in the answer. So I don't have a problem with a diagram that leaves them off. But I also see the other side of the argument, which is that most trust problems require more than self assertions for issuance, and most require comparing received data to data that is outside the control of the sender for validation. The 3-party diagram correctly shows the additional dynamics that are very often important, and there is value in that.

Bottom line is that I don't think either diagram is suboptimal; they just have different contextual sweet spots.

Re. IPR: I don't know enough to have an opinion.

[mwherman2000]

The intent of the Raw Credential Sender-Receiver Model is to serve as the most basic architectural pattern (a set of axioms or an algebra) from which new application-specific _specializations_ can be derived; for example the 3-party Issuer-Holder-Verifier model.

The 3-party Issuer-Holder-Verifier model is an example of a specific application scenario related to wallet-type applications.

As such, the Raw Credential Sender-Receiver Model belongs in Layer 2 of the TOIP Trust Spanning Layer Framework; the 3-party Issuer-Holder-Verifier model belongs in Layer 3 (as an application specialization).

Here's an amalgum to illustrate the concept of the 3-party model being a specialization of the 2-party model...

*https://en.wikipedia.org/wiki/Verifiable_credentials#/media/File:VC_triangle_of_Trust.svg

Re: IPR: I don't have any IPR issues either.

[mwherman2000]

For completeness, below is a Layer 3 2-Party Verifiable Credential Sender-Receiver Model, a specialization of the Layer 2 2-Party Raw Credential Sender-Receiver Model...

[JFleenor]

In response to the Issuer/Verifier/Holder model vs a two person model, I appreciated Daniel Hardmans response. It would be nice if we could represent both in the paper somehow, showing that one does not preclude the other, and it depends on context of what is being done.

Regarding the images. I do not like the "anonymous" looking figures. Any depiction of people should use our ToIP images color look and feel.

[talltree]

The three-party model applies to the roles of issuers, holders, and verifiers of digital credentials. It is a well-understood model in any system of credentials (even physical credentials) because the duties of an issuer relative to the job of issuing a credential are completely different than the duties of the verifier in verifying the credential — to say nothing of the holder role which is completely different from either issuer or verifier.

More importantly, the three-party model is called the "trust triangle" because it explains how transitive trust works, which we broke down into the constituent principles in the Design Principles for the ToIP Stack V1.0.

Furthermore, the ToIP Technology Architecture V1.0 Specification intentionally only depicts the trust triangle in one place — as an example of one typical Layer 3 trust task in the conceptual diagram in the Introduction — and only mentions the role of "issuer" in 3 places. That was deliberate because at Layer 2, the architecture is inherently peer-to-peer, i.e., the Layer 2 trust spanning protocol applies to any interaction between any two ToIP endpoint systems just like the IP protocol applies to any interaction between TCP/IP endpoints.

Net net: I don't see any changes required in the ToIP Technology Architecture V1.0 Specification, and suggest this issue be closed.

[mwherman2000]

Regarding the images. I do not like the "anonymous" looking figures. Any depiction of people should use our ToIP images color look and feel.

These images are DIDComm Notation elements, the graphical language used to design decentralized systems using the Web 7.0 DIDComm-ARM (the equivalent of ArchiMate for decentralized systems architecture). Reference: https://hyperonomy.com/2022/12/18/web-7-0-didcomm-agent-architecture-reference-model-didcomm-arm-0-40-december-18-2022/

@JFleenor Footnote: I'm not sure where you got the impression the DIDComm Notation element was a "person" or a "depiction of people". It's very specifically a DIDComm (software) Agent; hence, the choice for an agent's graphical representation. It's an important distinction that I highlight here (slides 36-50): https://www.youtube.com/watch?v=AFmCv8cfkm0&list=PLU-rWqHm5p44AsU5GLsc1bHC7P8zolAAf&index=1?t=2606s

[dhh1128]

I'm just noting one way that we may be talking past each other here.

I believe Michael is using the term "credential" in a different way than the rest of us do. If we use Michael's definition of credential -- a collection of name-value pairs -- then it approximately maps to the concept of a DIDComm message and does not necessarily imply the trust triangle. Thus, it is a layer 2 construct.

Having acknowledged that possibility, I have to say that the generic definition of "credential" does not feel like a good one to use in ToIP contexts. It already has a carefully defined meaning that is different and more specific than that, and we should be consistent.

If we keep the established ToIP meaning for credential, then everything Drummond said about the trust triangle applies, and credentials in the ToIP sense are a layer-3 construct.

[mwherman2000]

I believe Michael is using the term "credential" in a different way than the rest of us do.

To be precise, my Web 7.0 models focuses on two terms: Raw Credential and Verifiable Credential. Please reread the latest versions of my postings carefully; specifically, https://github.com/trustoverip/TechArch/issues/83#issuecomment-1399299927.

What you see is the evolution of a succession of more and more refined specializations of the Raw Credential Sender-Reciever Model (Layer 2) into the Verifiable Credential Sender-Reciever Model (Later 3) into the Issuer-Holder-Verifier Model (also Layer 3). ...that is, a hierarchical taxonomy of credential sender-reciever models. This is extremely powerful especially if you're trying to attract software architects and developers to your platform (e.g. Web 7.0). ...but perhaps too detailed for the TOIP TAS documentation?

[talltree]

@mwherman2000 I don't doubt that it is very powerful — and I agree, it's too deep for the ToIP TAS spec. But I'm sure it will come up in various component specs.

[mwherman2000]

I created a new tutorial that summarizes the latest information from issues https://github.com/trustoverip/TechArch/issues/83 and https://github.com/trustoverip/TechArch/issues/84.
If you have been following either thread, there is also some new data and graphics. Check out Web 7.0 Trust Spanning Layer Framework 0.57 (https://www.youtube.com/watch?v=rrFfuUHHmr4) NOTE: It may be a few hours before YouTube has finished post-processing the video.

With this note, I'm closing both of the issues: https://github.com/trustoverip/TechArch/issues/83 and https://github.com/trustoverip/TechArch/issues/84.