Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 6 Next »

Meeting Date

  •   TWO MEETINGS
    • NA/EU 07:00-8:00 PT / 15:00-16:00 UTC 
    • APAC 1:00-2:00PM PT / 21:00-22:00 UTC  <== NOTE THE NEW TIME - 2 HOURS EARLIER THAN LAST WEEK

Zoom Meeting Link / Recording

Attendees

Main Goal of this Meeting

Review new ToIP protocol stack diagram submissions and (if Daniel Hardman is able to attend) discuss how our requirements for the "hourglass neck" protocol compare to the requirements for DIDComm V2.

Agenda Items and Notes (including all relevant links)

TimeAgenda ItemLeadNotes
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 minReview of previous action itemsChairs
15 minsQuick summary of new ToIP protocol stack diagrams added this past weekDiagram authors ==> 

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

30 minsDiscussion of the Hourglass Principle and DIDComm V2Daniel 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 (wink)
    • 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.
5 mins
  • Review decisions/action items
  • Planning for next meeting 
Chairs

Screenshots/Diagrams (numbered for reference in notes above)

#1


Decisions

  • Sample Decision Item

Action Items

  • Sample Action Item


  • No labels