Drummond Reed

Daniel Hardman 

Samuel Smith 

Darrell O'Donnell

Sam Curren 

All

See this Github discussion for more about the Two-Layer Design Model Proposal. The purpose of this proposal was to see if we could achieve alignment by compartmentalizing which problems were solved where.

Daniel Hardman 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.

Wenjing Chu understood Daniel's argument for a number of his proposed features but does not feel it needs to be in Layer 2. His test would befelt that a different test should be used for whether a feature MUST be in the trust spanning layer, "If a feature is not NOT included in Layer 2, it would be hard to implement in a higher layer." Sometimes 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 very strongly that the properties he is talking about 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.

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 _________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.

Samuel Smith made the distinction between trust issues and reliability issues. He feels the latter are important, but that the core problem is the trust-across-domain-boundary problems. So he would prefer to focus on keeping the TSP layer as thin as possible but keep those 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 . He agrees that there are other related problems that we 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 Samuel 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. An He gave an example of a trust task that is may not need to cross trust boundaries is a biometric verification: 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. That 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 across trust boundaries is that there are many solutions within the trust boundary. But the TSP needs to focus on across trust boundaries.

He also clarified that the "upper part" should belong to Layer 3.

Drummond Reed did a check with the group about there be a single protocol at Layer 2 that serves as the trust spanning protocol. 

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

Antti Kettunen felt that the more features at the lower layer mean 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 can change over time as the computing world changes — for example most Internet traffic used to be over TCP, but now it is 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 so that it can be as thin as possible. That will result in the most durable TSP.

Drummond Reed made the point that adoption will work from the top of the stack down. ____________

Jo Spencer feels that we need an anchor at the base, which is the TSP, that provide 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 suggested 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 felt "feedback" would be more important than "alignment" because the latter would mean they depend in both directions.

Daniel Hardman shared screenshot #

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

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 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.

Wenjing Chu said that the right side means that the market will choose (developers will choose) to use the TTMP layer. 

Drummond Reed spoke about DIDComm being a potential at the next layer. _______

Wenjing Chu also liked DIDComm and others _______

Drummond Reed talked about _________

Wenjing Chu talked about next features ________

Jo Spencer what capabilities are required at the TSP layer and the TTMP layer.

Samuel 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.