New diagrams (links go directly to the slides in the ToIP Protocol Stack Diagrams slide deck):

• Antti Kettunen here
• Scott Perry here
• Tim Bouma here
• Daniel Hardman here and here
• Drummond Reed (building on Samuel Smith, Wenjing Chu & Daniel Hardman) here and here

Daniel is one of the primary authors of DIDComm V1 and DIDComm V2. Topics to cover:

• Why and how does the Hourglass Model apply to the ToIP stack? (See the Design Principles for the ToIP Stack draft currently in Community Review.)
• What are the requirements for the "waist" protocol (the "trust spanning layer")?
• To what extent was DIDComm designed to meet those requirements?
• Is there any other protocol that is a good candidate to meet those requirements?

Daniel's list of requirements of a spanning layer for trust:

1. must be based on DIDs;
2. be transport independent/agnostic (not just useful over many transports, but over combinations of them, so we can have trust without being captive to transport providers);
   1. Example of Alice and Bob using NFC for an introduction and then HTTPS to complete a conversation
3. must answer the "how" of cryptography from DID doc;
4. answer the "where" of interacting from DID doc (e.g., the service endpoint);
   1. There can be exceptions, but generally speaking this is respected.
5. support both on and off the record;
   1. Many use cases require that you can prove what you said, but other use cases require you to be able to be private.
   2. Example of the latter is a whistleblower.
6. be composable;
7. not require client server;
   1. It can be supported, but must not be required that one node be an always-connected server.
   2. It must that either one can come and go.
8. support simplex
   1. The way Alice sends a message to Bob may different from how Bob responds.

DIDComm is the only protocol Daniel is aware of.

• If we modified Matrix, we'd get about 2/3 of these features

Daniel thinks it is possible that there are alternatives for the spanning layer, but DIDComm could be the default protocol.

• DIDComm V2 adds some additional features that go beyond this
• For example, DIDComm V2 uses the JOSE family of specs, but that's not a trust requirement
• DIDComm V2 is also more efficient that V1.

Discussion:

• Antti Kettunen asked about the use case for reading and verifying a VC
  • This involves a single DID
  • Does this involve a simplex connection
  • Daniel responded that in DIDComm V2 they did not want to require connections. They called this "zero-round-trip". So it does support "one-sided" connections where there is an assymetry of trust, where only one party needs to have trust.
  • So in this scenario one party emits data and the other party verifies it.
  • Antti asked whether that was the same as simplex behavior.
  • Daniel replied that simplex is different transports in either direction. There is no required relationship in the other direction.
• Daniel wanted to add some thoughts
  • The "narrow waist" looking down means there can be a rich set of transport protocols.
  • The "narrow waist" looking up needs to support a rich set of composable protocols.
  • He used the example of different protocols used at a fast-food joint
    • The "order a hamburger" protocol
    • The "do you speak my language" protocol
    • The "do you take credit cards" protocol
    • The "will talking louder make a difference" protocol 
  • These are all examples of composable protocols — they all work together
  • Another factor is cost and the ability to negotiate payment
  • Daniel cited the example of Verifiable Presentations (from DIF)
    • It tried to cover negotiation by asking for one more field to verify the issuer
    • A better solution would be composable protocols
      • Jump into the "challenge the issuer" protocol
      • Then the "payment protocol"
  • In talking about "trust tasks", each task can correspond to a co-protocol (or set of them)
  • In DIDComm V2, each protocol has a "goal code". 
    • An example is a goal code for payment.
    • Goal codes are a general property of DIDComm.
    • Another property of DIDComm is that any co-protocol that supports a goal code, they must support a standard set of inputs and outputs.
    • The abstraction of being able to support multiple goals as the two parties need them is a a feature of DIDComm.
    • This is the same type of abstraction as calling a subroutine in programming. The developer does not need to care how it is done.
  • Antii shared that combining those protocols is exactly what an ecosystem does.