Sam Curren kicked off the meeting with a presentation about layering inspired by the current architecture of DIDComm V2.

Samuel Smith asked a question about how trust task data can be verified across multiple trust tasks.

Sam Curren: DIDComm does not have an opinion about payloads. Signed trust task data could be defined at any layer.

Samuel Smith: It should be something that could work across all trust tasks. Needs further discussion.

Wenjing Chu: First, he likes the picture and the general thoughts. He thinks of the trust task layer as "wide open". This is good, as developers will figure out many different ways to use the TSP layer.

He also likes that on the bottom layer, the picture supports both message-based and non-message-based. Wenjing would put that layer above the TSP.

In Wenjing's mind, the TSP is a combination of some part of the signing and some part of the encryption layers. Those would become the Inter Trust Domain Protocol. That would be the very stable and adaptable layer. Changes should happen below in the support layer and above in the trust task layer. That way changes can happen above and below while the ITDP stays very stable, which is why we want to keep it as simple as possible.

Sam Curren believes that we need one clear name for the TSP layer and one for the full set of layers.

Wenjing Chu believes strongly that we need one and only one protocol at the narrow piece, and it should have its own name.

Sam Curren agrees that the combination of the layers he's proposing should have a different name.

Antti Kettunen felt that it is vital to have maximum flexibility at the trust task layer. He also agrees that interoperability is critical, and also stability, which is why he agrees with Wenjing that the minimal TSP layer has to be very stable.

He also feels that liability must be able to be addressed by the full stack.

Sam Curren posits that we should use DIDs as an identifier metasystem. We can either define a profile of the DID spec that imposes certain requirements on specific DID methods. For example, it could be that only DIDs that are AIDs.

He also believes that liability should be addressed by governance layers. The TSP layer should only assure authentication.

He supports interop with legacy but only so far as it doesn't become a hindrance to significant new functionality.

Samuel Smith feels we should not call any specific layer the "spanning layer", but rather call the layers functionally what they do. Then when we are all said and done, we have a set of layers that are easy to describe individually. One will emerge as the "spanning layer" for this stack. But in the future there could be higher spanning layers.

Sam Curren said that "premature labeling of the layers would be chronological snobbery".

Samuel Smith said that it is best to make the layers as thin as possible. Then the spanning layer will become clear. If you can't decide about any layer, make it thinner.

Sam Curren agreed. 

Antti Kettunen "What I meant by liability, is the ability to follow possible identifiers to an entity that can/will claim liability from governance perspective. I.e. an org can provision capabilities to an autonomous car, but when that car runs over a person, there needs to be non-repudiable identifier hierarchy that can be traced back to a legal entity identifier that claims liability over the device. This is a simple example, but I assume we would see more complexity in the identifier hierarchy along the way (drones, assets, etc)."

Samuel Smith explained the history of the way that the TCP/IP "splitting out" different layers as needed.

Wenjing Chu said that he believes the Internet stack is a good example of how a layered protocol stack evolves. It is best to stay focused on a specific problem. That is more doable for us, and will also be more durable.

So when he thinks about the TSP, he believe the core problem it needs to solve is connecting across trust domains. The reason this protocol will become so enduring is that it is such a common problem.

Even the IP protocol actually requires several other protocols to actually work. So the more decompostion we do, the better.

So that's why Wenjing proposes just solving the Inter Trust Domain Protocol first.

He also pointed out that the move from IPv2 to IPv4 was very difficult because the address format changed. He hopes we can avoid that mistake.

But he also wants to make sure that our protocol stack is as easy as possible to adopt.

Sam Curren again advocated that we profile the DID Core spec in order to take advantage of an identifier metasystem.

He also agreed that we could further split up the layers from what his diagram. This allows us to proceed with gaining adoption — and the experience gained by actually implementing and using. The TCP/IP stack evolved the same way. (But we should not be intentionally reckless.)

Neil Thomson