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

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.

"One way to clarify this concept is that the TPS defines compliant profiles of other protocols that are used in the Trust Protocol Stack. So leveraging dids as a spec is limited to only those did methods and usage of those did methods that fit the defined TPS profile."

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 advocated having use cases for verifiable data and relationships will help with our design. For example, what is cross-verifiable across trust tasks. An example is two digital trust ecosystems that use different identifiers. How does Alice get back to Bob's "side of the fence" to appraise the trust basis for his ToIP identifier. And this must be done at the lower layers.

Sam Curren the most important problem we need to solve is how parties can connect and determine the trust they can have in the other. He gave the example of governments that will require certification of software and hardware being used by ToIP stack participants. This already applies to some security issues today.

It is important to make sure that the lower layers support what is required to solve that problem at whatever layer(s) need to solve it.

Having an identifier system that lets us resolve to a key and and endpoint is the essential piece.

Once you have that, Alice can either "phone home" to Bob's digital trust ecosystem to verify him, or she can request VCs to do it.

Drummond Reed shared that he does believe that verifiable identifiers (VIDs) that would qualify for use with the TSP can all be expressed as DID methods, so he is in favor of profiling the DID Core spec.

Darrell O'Donnell very much likes Sam Curren's presentation. Darrell has always believed that the output of this TF is likely to be a refinement and decomposition of DIDComm. So he likes this direction.

Samuel Smith wanted to address the different options for appraising trustability of another party. In addition to "phone home" and VCs, there is a third option of imposing requirements via governance or contracts that another party agrees to. Provenance through chaining is then a way to be able to verify that information. Historically we have not looked carefully at approaches like delegation and provenance verification. Those have tended to be pushed to higher business logic layers. But many of those things to be done well must be supported at the crypto layer. So you have to build it in there.

Sam Curren said that he thinks there is a better name for what he called the "crypto layer" as there are other things that have to be done at that layer. If we get the foundations right, we can build fantastic things on top of that.

Wenjing Chu is proposing that the Inter Trust Domain Protocol (ITDP) is trying to be very precise about what it is trying to do. For example, each trust domain can have its own DID method. The ITDP does not itself create any new trust. It only provides a way for the two parties to convey to each other so they can each appraise the trust basis of the other. Some may be cryptographic, but some could be out-of-band, or based on governance frameworks, or something dynamic through a trust registry network. So the ITDP can connect across any set of trust domains that want to use the protocol.

In addition, Wenjing is agreeing that there could be many different layers. For example, a stock trade may involve a whole bunch of layers and credentials that are in different layers. They may combine cryptographic layers and other protocols to supporting systems. So what we need to guarantee in the ITDP layer is that we need a trustable identifier. This needs to be a very precise and defined concept, so different DID methods can be used on top of it.

Sam Curren was in violent agreement that the system must provide a way for the parties to evaluate and establish trust but does not guarantee trust.

He also believes that if this decomposition and layering of the components may in fact become effectively "DIDComm V3".

Drummond Reed suggested that if we have a general consensus about the need for this "thin layer" approach, it would be good to start do discuss how we would proceed with defining these layers, i.e., what specific tasks should we start tackling in what order.

Wenjing Chu wanted to caution that once the stack is decomposed and defined, it won't be just "DIDComm V3" because it should also support other applications that may not fit the same design requirements as DIDComm.

He also agreed that we need to define a set of requirements for ToIP identifiers that could be a profile of the DID Core spec, but which does not have to be limited to that spec.

However we also need to be able to build into the ITDP the capacity for appraisability of trust domains.

Sam Curren agreed that the result of our work would no longer be "DIDComm", but actually a superset of what is currently covered by DIDComm V2. For example, he would love to see group messaging to be handled by the resulting stack.

Samuel Smith said he doesn't want to have "chronological snobbery" by assuming we know what the layers are. Rather we need to figure out the layers. If you can't figure out a layer, you split a layer either vertically or horizontally. And you see what works. The reason for this is he has concerns "all up and down the stack" that if we are too opinionated about certain things, we preclude the best security approach. But that also applies if we are too loose, we won't get good security.

One of his goals is a profile that can provide "the best security reasonable possible". Most standards go for the lowest common denominator. And that results in unfixable designs with "structural flaws" that you can't fix.

He wants to make sure that in the end, there is a way to use this trust protocol stack that is "the best that you can do".

Sam Curren kept an outline of steps, see screenshot #

Samuel Smith suggested an iterative process where we evaluate layers and then decide to split horizontally or vertically as needed.

Wenjing Chu is overall agreeing with this sentiment. To clarify, he feels the goal of ITDP is specifically about interoperability — so it could support both KERI and DIDComm and other protocols (e.g., DWN). Thus as soon as we have that, we can start to compare what works.

Back in the early days, one big concern was reliability and comm links. That was thought to be hugely important. But the IP protocol came along and said it didn't need all of that, so it just solved one problem. So it allows higher layers to have different choices. Yes, everyone wants to see "the whole cake, including the frosting and the cherry", but there can be multiple cakes.

Drummond Reed clarified that what we are proposing here is a protocol stack that consists of either:

1. Profiles of other existing specs.
2. Specs we write.
3. Profiles of specs we right.

Samuel Smith proposed that we include the notion of LOAs that can be accomplished by profiles of layers or combinations of profiles.

Sam Curren liked that idea and proposed that we can horizontally define a layer and the