Proposal #3: Wenjing Chu

[wenjing]

This is the thread to discuss Proposal 3. I'll provide links/references after the presentation meeting.
The following links have been updated to include the second part presentation.

Here is the link to slides: https://github.com/trustoverip/trust-spanning-protocol/blob/main/TSP%20is%20an%20Inter-Trust%20Domain%20Protocol%20(ITDP).pdf

And the recording of the first presentation (sections 1-4): https://zoom.us/rec/share/e0QA2wkxRHm1ZiJUArxXKQmJjhVnlrbqc69L4V7iTuNd2hyYO-myVxo2YG5ZNVqt.Yr--8yysWI1ctdTm

The recording of the second presentation (sections 5 and 6):
NA/EU Meeting: https://zoom.us/rec/share/_Rf0dGbj4M34vY2736n2ZJXe5hMS0gAshpq0QnvbZy0lCYOLOe-99Bx4Oii-caS4.uRj5aPAm6oWFMFsj
APAC Meeting: https://zoom.us/rec/share/B0r0TgWH6L1DEYNpOjSOr39Y-hPVnaKyjRy3yepcjH074qC0Zjo4NOBy5HJ30B__.VbmPu3iaaem4Gcyx

[Oskar-van-Deventer]

I am confused. Suppose that Trust Domain TD-A supports only DIDcomm, whereas TD-B supports only KERI. Would your ITDP then still connect the two? Or would IDTP be a negotiation protocol, where both sides agree to e.g. use KERI to keep their trust-relation keys synchronized?

Oskar

[wenjing]

@Oskar-van-Deventer I may not fully understand where the confusion is - this is the limitation of non-being-interactive. But let me make another try - if still not coming across I'll be happy to take the question up in a TF's zoom call. Maybe let me go back to your original example, a DIDComm only party and a KERI only party. Naturally, they can't interoperate on that basis. ITDP proposes a minimalist TSP that both DIDComm and KERI can support (because they are in some sense already doing it or can be easily decomposed or extended) - I'm proposing ITDP to ToIP's TSPTF as the candidate for the minimal Trust Spanning Protocol. I hope that part is clear. Next, DIDComm and KERI are not trust domains (they contain trust domains but not equal) - in the case DIDComm, you may think a particular DID Method defines a trust domain, e.g. DID-indy. In the case of KERI, we may envision a KERI-based DID Method, (don't have to but just to make life easy). So now we are trying to bridge some minimal trust of authenticity between DID_indy and DID_Keri. Now, I hope the last step should be apparent - each party can verify for authenticity based methods specified in their respective DID docs. Note: you may say, well, these two parties have different concepts of being authentic - yes, you are absolutely right. ITDP as a protocol does not enforce that - by the End to End Principle, that's up to the endpoint systems or users. As discussed in my response to Daniel - what interoperability and ITDP in particular does create is a "Pressure" which I believe will help users eventually converge on a smaller numbers of different schemes that best suit their own applications. More examples can also be found in the TechArch draft and I'll be providing more in the skipped Sections of my presentation slide deck when we can schedule a follow up. Hope that helps and thanks for the question.

[Oskar-van-Deventer]

@wenjing Thank you for the further clarification. I do like the concept, but I do not yet understand how it would work.

Would it be a fair to classify your proposal as an abstract proposal, which has yet to be further concretized?

[wenjing]

I see it quite 'concretized' proposal & can readily be implemented too - and TSPTF can move forward to writing the spec without delay. Also, majority of the code already exists or just need to be refactored, not rewritten from scratch.

[Oskar-van-Deventer]

I see it quite 'concretized' proposal & can readily be implemented too - and TSPTF can move forward to writing the spec without delay. Also, majority of the code already exists or just need to be refactored, not rewritten from scratch.

@wenjing Wenjing, my apologies for remaining confused. I asked a yes/no question, but I did not get a yes/no answer.
The reason that I consider your proposal "abstract" is that I don't see any elaboration HOW your ITDP protocol proposal would work. Could you provide me an example of an ITDP protocol exchange between "Alice" and "Bob", and what type of information would be carried in the ITDP headers, please?

[wenjing]

Here let me rephrase my last comment: "No, I would not classify the proposal as an abstract proposal, which has yet to be further concretized'. I see it quite 'concretized' proposal & can readily be implemented too - and TSPTF can move forward to writing the spec without delay. Also, majority of the code already exists or just need to be refactored, not rewritten from scratch." Hope that directly answers the yes/no question - which I don't think the best way to answer it as I will explain below. For your second half ie elaboration of HOW - which are the subjects of the two 'left blank' sections in deck. I had only 40 min to present so I focused on what are really important aspects that stands in contrast with and compliments the "forerunners" as well as Sam/Daniel proposals - the complimentary property is the crucial feature for interoperability between trust domains. In other words, the detailed format is left unspecified for the moment is a sign of the type of interoperability this protocol aims to achieve and part of the reason that it can adapt to meet many trust framework requirements. If this is what you meant by "abstract" as something that is adaptable or meta, then yes - I would agree (but it's hard to tell based on text alone, hence my avoiding of a yes/no without really knowing what you meant for sure.). But such adaptability is a goal of the protocol - it is not something that we would remove by "concretization". That's the huge difference! And the reason the answer is 'no' to your direct question. The IP (Internet Protocol) is considered abstract too - as it doesn't even have a frame format! That's a feature not a bug. So the details would involve the adaptation procedures which directly relate to DIDcomm/KERI/Others, and message types (which might be what you meant by 'headers'). The discussion of these procedures were included in the deck. I look forward to further discussions and showing examples in a followup meeting when the TF is able to schedule. Thanks again for sharing your feedbacks.

[wenjing]

In the NA/EU meeting, Daniel asked a great question on the "pressure" that ITDP may produce in the overall solution space. ITDP itself only help convey trust signals between trust domains, it does not create new trust signals that are not already in existence in their respective trust domains. But an Inter-Trust Domain Protocol - its interoperability - does potentially create a "pressure" - that would push the ecosystem in a direction that favors many benefits we desire (eg privacy, interoperability, decentralization, ... and so on). I thought Daniel's term "pressure" is a very appropriate one. When the Internet Protocol was introduced, it didn't explicitly pick Ethernet as a favor - but once interoperability based on IP is possible, consumers of the LAN technology can choose their favorite - and they chose Ethernet. The same mechanism could work here with ITDP.

[talltree]

I too like the term "pressure" (or "adoption pressure"), and I definitely believe it will work this way with Trust Supports at ToIP Layer 1 just like it did with the LAN networking protocols supporting TCP/IP.

[wenjing]

In today's NA/EU meeting, Sam asked a great question after my presentation. It's about how ITDP may pair with other protocols. I want to summarize that q&a here. I see - as normally how protocols tend to evolve - we may eventually get a suite of protocols. Some protocols may "partner" or "pair" together very commonly, but not exclusively. Since ITDP is not intended as a primary data path protocol, it will often (not always) pair with some data path protocol. People may choose different data path protocols for many reasons - and that data path protocol will deal with formats/encoding/performance/efficiency/communication patterns ... many considerations. ITDP can work/partner with many of them but does not specify one in particular.

[talltree]

@wenjing For those of us not as familiar with the term, what are some examples of "primary data path protocols"? Is that a more exact way of saying "transport protocols"?

[mwherman2000]

In the APAC meeting, I offered the following explanation @talltree. There are 2 scenarios:

1. Attachments (data) embedded in the actual message
2. Attachments (data) associated by reference in the actual message (e.g. a URL element in the message that dereferences to a blob in IPFS)

Point #1 is handled by the plain old Layer 2 TSP - for example, think of DIDComm and an embedded DIDComm Message attachment.

Point #2 is handled by a Layer 3 Trust Tasks Super Protocol. The message acts like a control/signaling channel (control/signaling path) and the blob in IPFS, as an example, acts as the data channel (data path).

I describe this in slide #30 of the Proposal 4 presentation: https://hyperonomy.com/2023/02/22/proposal-4-to-toip-tsl-tf-web-7-0trust-spanning-layerframework/ (reproduced below).

What is a Layer 4 Trust Tasks Super Protocol? Slide #29 introduced the new concept of Layer 3 Trust Tasks Super Protocols and Super Protocol definitions.

[wenjing]

@wenjing For those of us not as familiar with the term, what are some examples of "primary data path protocols"? Is that a more exact way of saying "transport protocols"?

@talltree - it is not just a more exact way of saying "transport protocols". If we think about a hypothetical video streaming application, the viewers may want to know that the video is being streamed from an authentic source and the content has not been altered along the way. For such an app, the primary data path protocol will be the video streaming protocol which has its own protocol stack designed to best support video streaming. ITDP helps this app to establish the original authenticity and the basis of trust, but it is not carrying the actual video packets. ITDP does have its own "transport protocol" but that is orthogonal to the transport used by the video. Hope that helps to clarify.

[wenjing]

@mwherman2000 No, I was not primarily referring to "attachment or reference" when I used the term "primary data path". They could be examples of maybe 'secondary' data path carried within the ITDP messages. Again, please refer to the example I used in response to @talltree .

[a-fox]

@wenjing thank you for your presentation. I listened to it while on the move on my phone, so I wasn't able to follow intensively everything. I wanted to check if I understood your proposal correctly in relation to Sam's & Daniel's proposals.

It sounded like ITDP is a wider and more abstract protocol description that encapsulates all trust domain messaging, whether or not they use ToIP stack. Sam's & Daniels models together could be considered as one type of implementation of ITDP, as they seem to fulfill most of ITDP's requirements, or at least when I read some of the requirements, I could see them solved nicely with them.

Have I understood your viewpoint & context?

[wenjing]

@a-fox Hi Antti. I can't speak for Sam and Daniel of course, but I would emphasize the "Less is more" spirit of ITDP. I proposed that ITDP is the minimum required and a lot of other related protocols are very useful/important but not in the minimum set - this minimalism is a strength - it makes ITDP MORE valuable. It's also a way to separate concerns and focus on the core goal of bridging different trust domains. A proposal that offers more feature sets in a tightly bounded form within a 'bigger' protocol would in fact hinder / impede the goal of interoperability. So if we follow the spirit of the hourglass principle, I would to like to appeal to you that the ITDP's minimalist approach is the right way to go. Sam's and Daniel's proposals are more like a superset (I hope that's an ok way to describe) - but those extras, as I argued above, are hindrance - which I would like to see them as separate protocols (or "partners") and non-exclusive (i.e. not tightly bounded). I would love to see those "partner" protocols also developed of course - but not bundled together with ITDP. You can get a flexible suite of protocols that way. We could even reach such a state by decomposing some of the protocols that Sam and Daniel discussed. If you follow my answer to @talltree 's question - it illustrates the point with one example area - the data path. But that's not the only example. I hope that is clearer and welcome ideas of refining the minimum requirements. With the above explanation, I would agree with the sentiment of your last sentence - yes - they could work together nicely, IF they could be decomposed with a minimalist ITDP.

[Willem-de-kok]

Hi @wenjing,

Referring to Statement (6) in your proposal: "Speakers of ITDP are any generic endpoints with much constraints - ... .. could be any of above, all of above, none of above or any mix we can't yet imagine."

Why do you want to work with such an extremely broad definition of who the speakers of ITDP can be?
And do you find it a workable/practical definition?

[wenjing]

Thanks @Willem-de-kok. One of the design principles for ToIP happens to be THE principle for the original internet design - reachability is its own reward. To me, it means for a spanning protocol where interoperability will be decided, it should have as little constrain as possible. That's why I want to see all known hosts (any practical type) can be supported, and, future types which I hope we can attempt to maximize (again by removing any assumption that I don't have to make). So that's for the why. Is it workable/practical? Yes for all known common examples. I would like to see that if a device can have an Internet address and run an internet stack (or similar), it should be able to support ITDP as well. So yes, that's the point. As an example, a battery powered IoT sensor should be able to.

[Willem-de-kok]

Hi @wenjing,

Referring to Statement (15) in your proposal: "ITDP may function without a destination VID. If used in this way, it should mean 'to whom it may concern'..."

Could you mention a (set of) use case(s) where this could be helpful?

[mwherman2000]

The Publisher-Notify/Subscriber-Pull pattern used in several commercial data/content replication products and technologies including Microsoft Active Directory Domain Replication and Synergy Replicator for SharePoint
https://www.syntergy.com/resource_center/news_center/archive/2010_assets/LargestSP2010NetworkFINAL.pdf

[mwherman2000]

And regardless, this is not a base protocol capability. This scenario needs to be relegated/delegated to be a Layer 3 Super Protocol; although I could argue that this capability is really a Layer 1 Subprotocol.

[mwherman2000]

Here's an example of how best to explicitly model the Data Replication (Subscribe/Publish) Scenario using the Publisher-Notify/Subscriber-Pull Super Protocol...

NOTE: It only took a few minutes to draw this as a protocol derived from the Proposal 4 Layer 2 Trust Spanning Layer base protocol. This is a valuable indication of when something needs to be delegated/relegated to being a Layer 3 Super Protocol (derived from the Layer 2 Trust Spanning Layer Protocol (Base Protocol)).

The above model can be found in Appendix B of version 0.28 of Proposal 4 (slide 106): #27 (comment)

[wenjing]

In my example (which I called "Twitter-like clone"), publishers do not send to subscribers directly in a point-to-point fashion but rather through an intermediary (e.g. a "messaging service"). The intermediary as defined in ToIP Tech Arch is an outside system, not an endpoint - its design is therefore orthogonal to the endpoint as long as it is a proper intermediary system (e.g. not a trust dependency). This intermediary may implement a "push notification-like" service to trigger the pull by a subscriber. Such implementations would be consistent with ITDP but out of its scope.

[mwherman2000]

In my example (which I called "Twitter-like clone"), publishers do not send to subscribers directly in a point-to-point fashion but rather through an intermediary (e.g. a "messaging service"). The intermediary as defined in ToIP Tech Arch is an outside system, not an endpoint - its design is therefore orthogonal to the endpoint as long as it is a proper intermediary system (e.g. not a trust dependency). This intermediary may implement a "push notification-like" service to trigger the pull by a subscriber. Such implementations would be consistent with ITDP but out of its scope.

@wenjing This is a centralized architectural design and deeming the centralized service to be "out of scope" IMO doesn't make acceptable assuming we're committed to a decentralized architecture.

I believe this use case/scenario/approach needs to be summarily dismissed - in favour of a fully decentralized design that does exist.

[Willem-de-kok]

Hi @wenjing,

Referring to Statement (11) in your proposal: "ITDP needs to support a generic identification that can be efficiently mapped to trust domain specific addresses AND can be verified for authenticity (verifiable). ... The actual implementations of such generic verifiable identification are out of scope."

How can one efficiently and accurately speak about generic (verifiable) identification when the speakers of ITDP are generic endpoints (not further specified)? What does generic identification mean?
How can the generic verifiable identification be out of scope?

[wenjing]

DIDCore for instance specifies a generic identifier without specifying how it is realized. So, to answer your question directly, it means we specify formats and operations that other components in the system can use, but does not say how it is implemented. Of course it doesn't mean we don't care how it is implemented, we do. We may list how various implementation may look like, including existing examples and future hypothetical examples. If we may use the Internet Protocol as an analogy again, if you read IP spec RFC, it doesn't tell us what a host look like, does it have x86 or ARM, does it have 10BaseT ethernet or 5G cellular, does it have 110v power or a CR2032 battery - these are out of the scope of the protocol spec. They matter a great deal to a product designer. So IP address is a generic identifier. For verifiable identifier, we just need to ensure it is "verifiable" (in addition to being a good identifier) - and that aspect can be specified by a small set of "Operations". DID is a verifiable ID because DID Doc can provide how to verify it. For your last line I think it's an error? My statement (which you copied) says "The actual implementations of such generic verifiable identification are out of scope". The implementation methods are out of scope for the protocol spec itself. We naturally will be intensely studying them and experimenting them, but it is not part of the spec. This allows future developers the freedom to come up potentially much better implementations without having to lose backward compatibility, interoperability, or the cost of a complicated migration etc.

[wenjing]

Oh, the efficient mapping part. If we assume a generic host - a computing device with some basic facilities. The cost of mapping (ARP) can be accurately estimated for such operations. If we combine that with experiments and measurements, we should be able to come up with a reasonable cost estimate and then decide if it is efficient enough. The main marginal cost will probably come from the cryptographic primitives these devices need to compute and/or message rounds and external accesses etc.

[Willem-de-kok]

Thank you for your response.

I can understand that we want to leave implementations of generic verifiable identification out of scope.
However, I can imagine that we will make a kind of blueprint, containing some basic assumptions, for what a generic (verifiable) identification method might look like. @wenjing is this what you also have in mind?

One might respond to the idea of making a kind of a blueprint, saying: "Once we have made a blueprint, we have already ruled out possible implementations of generic verifiable identification methods, so a blueprint will not make the ITDP proposal a minimal proposal for the TSP layer." My response would be: it is also a trust layer, not only a spanning layer. There are very many different designs for a verifiable identification method. Therefore, I would propose that, as the ITDP is a trust layer protocol, there should be some 'lower bound of trust' guaranteed. The lower bound is only there if the ITDP contains some specifications regarding what a suitable trustworthy verifiable identification method would look like, i.e. the ITDP needs a blueprint for verifiable identification.

Is my above reasoning valid?
Furthermore, as it is really arbitrary what 'the lower bound of trust' might be, would you respond that there should not be a lower bound, and thus no blueprint? Or do you expect that the community can reach a consensus with regards to what a 'lower bound of trust' might entail?

My apologies for asking so many questions in one response.

[wenjing]

Thanks @Willem-de-kok - your reasoning is largely aligned with my proposal. In fact, the "lower bound of trust" is explicitly listed in my proposal as statement (11) - which is also what your question is about. It says about 2 things: the VID itself and "authenticity". So to say it in another way, the "lower bound" is VID and authenticity. This lower bound allows trust to be spanned across trust domains. i.e. it is sufficient. It is also necessary - removing any one of them, it won't work. That's why these 2 are the right choice for ITDP or trust spanning. Authenticity is about both the source (VID) and the message from the verifier/receiver's perspective. If you are interested in deeper discussions around what authenticity means - take a look at this trustoverip/TechArch#10.

With regard to the notion of "blueprint" - I think it depends on what you exactly mean. We all have a blueprint - I suggest you take a look at my beginning slides where I talked about the Reference Architecture - that's my mental model in high level. You could also take a look at the Tech Arch document on the reference architecture section and section 8 to some extent. So the high level mental model is about a receiver who assesses a message and its source to be sufficiently assured that both are authentic. In this task, the assessor (or verifier) does have access to additional resources (which are supporting systems in my terminology). I try to keep this abstract blueprint/mental model as general as possible.

To your final question - yes - I do believe we can reach consensus on this lower bound. First, we have gone through a good phase of discussion on this already during the Tech Architecture spec draft process. Second, I have also done exercises with various known implementations to see if such an "authenticity" first view is compatible with their actual implementations and found encouraging evidences that indeed they can be made compatible with modest effort. I will share this part of info in my Part B presentation next week. And welcome your feedbacks!

[rodolfomiranda]

@wenjing , after reading the responses you made to the comments I think I now better understand your proposal. My struggle was between your point to make it as generic as possible but at the same time the thinnest. Looked contradictory in my mind at first glance, but you are right that’s what the IP part of the IP stack does.
I’m still trying to figure out how a reference implementation should be described. I think that you need to define the interface with the upper layer (in and out) and the interface with the lower layer (in and out). Do you think that those interfaces should be determined in a generic way or in a per case by case basis (per trust domain and per supporting transport) ? what should be the minimum properties/requirements that they should handle?

[wenjing]

Thanks for the comment and questions @rodolfomiranda . The interface to the lower layer has a lot of coverage in my proposal slides. This interface should be specified in a generic way and then each implementation may choose to a concrete method. The generic interface is described in terms of secure execution, secure storage and transport. Most people think of the transport because that's the networking part. We need a transport protocol e.g. HTTP(S) or WebSocket or TCP or UDP - i.e. it has to be Internet layer 4 or equivalent or higher. This interface can be generalized and that's what we should do. The use of this interface also requires an ARP (address resolution) mechanism. This part is also well described in my proposal slides (in both directions). Putting this together, one would have all the details required for coding up the protocol. Now, there are other factors that L2 cares about, specifically verification of VID and appraisal of supporting system of the trust domain, these protocols are also similarly generic interface with plugin-like implementations specific to each supporting systems. On the interface between Layer 3 and ITDP or the upper interface has less coverage in my slides, but it is illustrated in examples section in simple ways. The upper interface is a relatively straight-forward messaging interface - with up and down directions (or in and out as you call them). If you find such description too abstract for comfort, the picture can be very much simplified if we assume a specific trust domain, say DID/Aries and using HTTPS. That would be a fine example for reference implementation as long as we keep in mind that the interfaces to DID and HTTPS etc are generalized and can be replaced.