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.
  • ACTION: Drummond Reed to capture Daniel Hardman's proposed requirements in the ToIP Technical Architecture Specification draft document.

Jo Spencer ran us through his slides and thinking

• We are not going to change other systems or ecosystems, so we need to figure out how to work with them, both technology and governance.
• We are trying to create "better trusted interactions" between participants
• Tim agreed: you can't tell existing systems to change their design or terminology
• Jo explained that this slide was created for the Sovrin guardianship work
  • It shows how different types of domain-specific governance fits
• Jo next explained his architectural approach
  • It is important to work from Concept ==> Logical ==> Physical
  • Operational perspectives are also very important
    • Real-time
    • Non-transactional
  • The trust triangle of Issuer, Holder, Verifier is very important
• This slide goes even deeper into Jo's architecture thinking
• The one principle that Jo felt especially strongly is "supporting migration and change". Portability is important.
• This slide is where Jo lays it all out.
  • Governance and Operations are split out so you can see those functions separately
  • He went over functions at each layer
  • He emphasized that payments were outside of this model - the actual exchange of funds
• Jo added one more slide here that is more transaction-oriented diagram. 

Tim next went over his slides that begin here.

• He is seeking a simple model that he can map against policy and implementations
• He tries to abstract away as much detail as possible.
• He also needs to take into account privacy, value exchange, government transitions.
• He mentioned the situation in Afghanistan about the identity system there falling into attackers hands
• Another example is the difficulties with vaccination certificates & the dangers of  "papers please" environment
• This slide is the heart of his model.
  • It shows tokens in the middle - they can go one way and become money and the other way and become identity. NFTs fit in the middle.
  • The left side has identity rights and the right side has monetary rights
• This slide Tim added to show a Wardley map that he's been evolving that shows how mature payment systems and how young that SSI, DIDs, VCs, and ToIP are.
• This slide is another overlay on top of Tim's four layer model that positions:
  • Identity systems
  • Trading systems
  • Financial systems
• Tim's motivation is not to build a system, but as a model for assessing policy frameworks.
• The commitments layer at the bottom are intended to be the "trust stakes" that have existed back to medival times.
  • Wax seals.
  • London exchange.
  • Amsterdam banks
  • New technologies are just new ways of creating trust stakes
  • Now we are using digital systems to do these same things
• Jo: Tim's diagram is "absolutely brilliant"
  • He asked about the "identity systems" label
  • Tim said that identity is about dealing with "sameness over time".
  • On the right side its is about dealing with "obligations over time".
  • Both are social constructs that we build upon.
  • Jo pointed out the interaction is also important.
• Tim pointed out that money is a social construct that changes over time depending on utility
  • The history of money shows the wide variety of options used.
  • Tim has been going back in time to capture how these systems have evolved, then synthesizing them together
  • This also extends to land rights and real estate — and the church and "control of the soul"
  • It brings an entirely new perspective to digital tokens and cryptocurrencies
  • It can have as much effect as gunpowder, steel, printing presses, etc.
• Jo pointed out that ALL of these systems deal with risk.
  • Time pointed out that time is uncertainty
• Darrell referenced this paper on a Swiss Blockchain doc that Tim mentioned: https://drive.google.com/file/d/17GnXXE6vr0kU4L-x55dNjLgBcH9h1xSt/view
• Tim mentioned that "legitimacy" and "authenticity" are