Time

Agenda Item

Lead

Notes

5 min

• Start recording

• Welcome & antitrust notice

• Introduction of new members

• Agenda review

Chairs

• Antitrust Policy Notice: Attendees are reminded to adhere to the meeting agenda and not participate in activities prohibited under antitrust and competition laws. Only members of ToIP who have signed the necessary agreements are permitted to participate in this activity beyond an observer role.

• New Members: Scott Lewis

5 min

Review of previous action items

Chairs

15 mins

Quick summary of new ToIP protocol stack diagrams added this past week

Diagram authors ==> 

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 @Sam Smith, @Wenjing Chu & @Daniel Hardman) here and here

30 mins

Discussion of the Hourglass Principle and DIDComm V2

@Daniel Hardman

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.

APAC Session

@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 

5 mins

• Review decisions/action items

• Planning for next meeting 

Chairs