All

Drummond Reed began by explaining that the purpose of the Two-Layer Design Model Proposal was to see if we could achieve alignment by compartmentalizing which problems were solved where. He pointed out the following comments on the proposal so far:

• Sam Smith raised questions in this context about different approaches to supporting composability.
• Darrell O'Donnell made some points about how TCP/IP required both TCP and IP to gain adoption.
• Jo Spencer spoke in favor of the "logical separation" of the proposal.
• Sam Curren suggested a specific set of five work items that could be a path forward.

Daniel Hardman then kicked off discussion with some thoughts about points he has made in the discussion by sharing screenshots #1 through #7 below from this slide presentation (which is also here: https://bit.ly/3oaR27Y). 

Wenjing Chu understood Daniel's argument for a number of his proposed features but felt that a different test should be used for whether a feature MUST be in the trust spanning layer, "If a feature is NOT included in Layer 2, it would be hard to implement in a higher layer." If a feature can be implemented in a higher layer and is not strongly required at the spanning layer, then it should not be in the spanning layer. This may leave some "ambiguity" at the spanning layer with regard to those types of features, but "sometimes ambiguity is useful in language".

Daniel Hardman felt strongly that the properties he has been describing cannot be at any higher layers without losing key qualities.

Antti Kettunen is open to the possibility that there are n layers above the TSP layer, and believes that is where the abuse is likely to happen. He suggests we should focus on the features that are needed by those higher layer to achieve Daniel's properties. "So… the L2 TSP is the one that spans (i.e. every single trust task uses it the same). And the Layer 3 TTMP includes overlays that are composable. On top of TTMP we create Trust Tasks that define the properties they choose to use from TTMP?"

Sam Smith replied "+1 to Should use the layer above".

Neil Thomson "Suggest a new term definition for what requires trust tasks vs. non-trust - interparty trust boundary."

Wenjing Chu feels that is important that we move in a way that we define the two layers at the same time. So that way, we can consider both sides of the problem will be considered at the same time.

Drummond Reed shared that the question of whether we can accomplish our objectives with two layers or whether it must be one is precisely why he posted the Two-Layer Design Model Proposal. So far it is eliciting exactly the different perspectives needed to decide about this question.

Sam Smith made the distinction between trust issues and reliability issues. He feels the latter are important, but the core problem is trust-across-domain-boundary problems. So he would prefer to focus on keeping the TSP layer as thin as possible to address the trust-across-domain-boundary problems, while at the same time keeping Daniel's other considerations/properties in mind as we design the minimal TSP layer because we do need to pay attention to those problems.

Jo Spencer returned to the original question of whether the TSP needs to be designed as two layers. He felt that Sam Smith and Wenjing Chu are focused on bottom-up design. He feels it is only necessary to separate the TSP layer from the TTMP layer if there is a good reason for the TSP to be agnostic about the layers above it and leave open the possibility of additional protocols at the next higher layer. The separation can be either a logical separation or a physical one. 

He asked whether a trust task is only a trust task because it must communicate across trust boundaries. He gave an example of a trust task that may not need to cross trust boundaries: biometric verification within an edge device like a smartphone (but then admitted that the trust application requiring biometric verification may need to cross trust boundaries within the phone).

So he's asking the question of whether it is helpful to separate the bottom up from the top down considerations.

Wenjing Chu said that the trust tasks at Layer 3 are going to be very numerous, and there will be requirements for types of trust tasks that we are not going to be able to anticipate. This suggests that there will be at least two higher layers, and maybe more. That again would focus the TSP on the "Inter Trust Domain Protocol (ITDP)" problem domain.

The reason for the focus of the TSP to be across trust boundaries is that there are many solutions within a trust boundary.

He clarified that the "upper part" in this discussion should belong to Layer 3.

Drummond Reed requested and received consensus with the whole group on the following axiom:

DECISION: There MUST be one and only one protocol at Layer 2 to serves as the trust spanning protocol. 

Daniel Hardman said that the two layer design model might be acceptable if the second layer is either required or highly expected.

Antti Kettunen felt that more features are available at the lower layer, the less negotiation is required. So he wants to look at the trade offs, but to do that, it would be more helpful to have more information about the business problems at Layer 3.

Wenjing Chu first wants to address the question about commonality. He used the examples of the two different host-to-host protocols — TCP and UDP — that evolved on top of IP. But that could (and did) change over time as the computing world changes — for example most Internet traffic used to be over TCP, but now less so. So layering allows for the evolution of those protocols. Whatever assumptions we make today about Layer 3 protocols may change. Other designers may have in mind other target contexts (such as IoT or factory floors), but they could use TSP too. So we should be humble about Layer 3 protocol design.

His second point is that, if we have no compelling reason to include a feature in the base layer, we should leave it to a higher layer so that the TSP protocol can be as thin as possible. That will result in the most durable TSP.

Drummond Reed made the point that adoption will actually work from the top of the stack down. For example, adoption of the TCP/IP stack did not start with developers adopting IP. Rather they adopted TCP (or protocols above TCP that used TCP) because that was the easiest path for them. And TCP used IP. The same will be true here, which is why if we agree with the Two-Layer Design Model Proposal, we should ensure that the TTMP is developed and delivered at the same time as the TSP.

Jo Spencer feels that we decide on a baseline set of expectations for the TSP. One example is time-to-live or message-expiry as potential base capabilities. If we have a "flex layer" above the base layer, the flex layer gives us the ability to understand what the base layer needs.

Wenjing Chu felt that if we are going to design the two protocols at the same time, it would be best to do it in separate task forces.

Jo Spencer thought it would be better to have "alignment".

Wenjing Chu said "feedback" would be more important than "alignment" because the latter would mean dependencies in both directions, whereas the TTMP should depend on the TSP but not vice versa.

Daniel Hardman shared screenshot #8 below and explained how it illustrated the choices we have in this discussion. "This visual is now the last slide in the deck that I linked to above (https://bit.ly/3oaR27Y)".

Drummond Reed loved Daniel Hardman's picture. So did many of the attendees in the chat.

Jim StClair "I really couldn’t follow things til this visual."

Willem de Kok agreed. "This visual was exactly what I somehow had in mind."

Jo Spencer said that it is an interesting option for trust tasks to "skip" the TTMP layer, but that most would not.

Wenjing Chu said that, with a protocol stack, developers always have a choice of the protocols to use and the levels. The only thing that we can insist on is that if a trust task crosses trust boundaries, it should use the TSP.

Daniel Hardman made the point that he was arguing for common semantics to be pushed down to the lowest layer. But he can accept that some properties can be at a higher layer.

Jo Spencer "+1 Daniel - We need the base construct to be catered for in the TSP. How that is used and what it means to the higher layers is determined at the TTMP+ protocols."

Willem de Kok "I hope that If Daniel (and we together with him ;)) can put all our passion in the TTMP and it becomes a very good one, then it could become the canonical one."

Darrell O'Donnell "This is what happened pre-TCP - there were oodles of inconsistent approaches right on top of IP. Thankfully things calmed down and we ended up with two - TCP and UDP. TCP had its abilities that drove many things into it. The UDP realm is where the things that didn’t fit with TCP landed in the UDP realm. Having 2 places where just about everything could fit was amazingly powerful. Having dozens or more is not empowering."

Antti Kettunen "We still need to understand the implications of layering design choice in regard to adoption & interoperability and what responsibilities are given to higher layers (e.g. application-level / Trust Tasks). Applications (e.g. websites in traditional web) grew in adoption because they didn’t need to understand lower levels or interior. Browser wars (JS) were a terrible example of interoperability problems due to poor layering choice. Adoptability of TSP Suite is critical and a wrong layer design choice affects adoption & usefulness on the application levels. Too much complexity, choice & ambiguity on application-level, and adoption probably becomes harder to achieve."

Jo Spencer "We just need to decide what goes in TSP and what isn't in TSP (and in TTMP, alpha, beta etc.)"

Neil Thomson agreed. "+1 to understanding the "trust task" primitives that are the compossible elements."

Wenjing Chu said that the right side of Daniel's diagram (screenshot #8) represents what we want to see happen in the market, i.e., that developers will choose to use the TTMP layer because it gives them what they need, just as they chose to use TCP rather than raw IP. 

Drummond Reed spoke about DIDComm being a potential candidate for what the Two-Layer Design Model Proposal calls (temporarily) TTMP.

Wenjing Chu also liked DIDComm at this layer just above TSP, and also suggested there could be others over time, both because they improve upon DIDComm, or because they solve different problems than DIDComm (just as UDP solved different problems than TCP).

Drummond Reed summarized that today's workshop appears to have produced a general consensus that:

1. The two-layer design model makes sense because it partitions the problem spaces.
2. Development of both the TSP protocol at Layer 2 and the TTMP protocol at Layer 3 should proceed in parallel (likely in separate task forces).
3. As a result, we need to start executing on a communication strategy (and a community strategy) to see who is attracted to work on each of these two layers respectively.

Jo Spencer "We also need a communications strategy!"

Wenjing Chu said he would be happy in the next TSP Workshop to prepare a set of slides proposing specific features of the TSP.

Jo Spencer seconded that step because if we follow this strategy, it is essential to decide which capabilities are required at the TSP layer and which are essential at the TTMP layer.

Drummond Reed shared that BOTH of these protocol names ("TSP" and "TTMP") are strictly temporary for purposes of these discussions, and that we should make it a separate effort — at the appropriate time — to decide on the actual protocol names.

mathieu "Thank you for the great productive discussion! Fascinating to listen to."

Drummond Reed took a quick poll and it was agreed that due to Internet Identity Workshop, we would cancel all TSPTF meetings next week (April 17-21).

ACTION: Darrell O'Donnell to request that Michelle Janata cancel TSPTF meetings next week, i.e., both the NA/EU and APAC meetings on Wednesday April 19.

The week after that is the Technology Stack WG Plenary meeting.

So our next meeting will be the Terminology Design Training Workshop in the NA/EU slot on Wednesday May 3.

We agreed to hold the next TSP Workshop at the same time as this one on Thursday May 4th.