• Start recording
• Welcome & antitrust notice
• Introduction of new members
• Agenda review

• 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:
  • Dima Postnikov works in financial services in Australia. 
  • Kapil Bareja has been working with Sapient working different aspects of identity

• ACTION: Judith Fleenor to create a Slack channel and a Google doc to start gathering suggested topics for a series of blog posts on eIDAS 2.0. 
• ACTION: Drummond Reed to move the agenda item for Bart Suichies to present his view of the stack in next week's NA/EU meeting.
• ACTION: Wenjing Chu to prepare for next week's call separate diagrams of the reference architecture view, where one is the stack implemented entirely on a local device such as a mobile phone (and thus the VDR is a local secure enclave or TPM 
• ACTION: Wenjing Chu to collaborate with Drummond Reed on deciding how incorporating the reference view of the stack should be reflected in the structure of the ToIP Technology Architecture Specification.
• ACTION: Drummond Reed to send Daniel Hardman a link to Wenjing's presentation and reference diagram for his feedback.
• ACTION: Drummond Reed to add to the storyline a requirement that Layer 2 must enable discovery, description, and basic negotiation of endpoints such that the endpoints can elevate to a Layer 3 protocol. 
• ACTION: Drummond Reed to add to the storyline that we want to include examples of the use of the interfaces at each layer to help them understand them.
• ACTION: ALL to continue work on the storyline slide deck (Google Slides) to see if we can complete the storyline narrative for the entire document within the next two weeks.

See the draft storyline deck. ADVICE - all hands review, digest and add/edit as you see fit.

• The background sections plus Layer 1 Requirements and Layer 2 Requirements are now drafted.
• Feedback on existing requirements and new requirements are actively solicited.
• Drummond will not be able to attend next week's meetings, but we should press on with progress.

Bart will present his perspective on the ToIP stack. See screenshots #1 thru #13 below.

• Bart said that his definition of trust is "a confident relationship with the unknown". Tim pointed out I think that was originally attrbuted to Rachel Botsman who wrote the book 'Who do you trust?' https://twitter.com/rachelbotsman/status/960094497274081280?s=20&t=5AstYnjw-Fn8GIQktbKBnA
• Vlad asked whether we are going to have to make a choice between DIDComm and KERI.
  • Drummond said there is an ongoing dialog between the DIDComm and KERI architects about how they can grow closer together.
  • Darrell shared his view that a number of features of KERI will migrate into DIDComm.
  • Vlad suggested that if we focus on patterns, we will find out which ones we need.
  • Bart suggested that we need to focus on architectural requirements for trustworthy systems, and then see which technologies fit those requirements.
  • Antti said that we will also need to explain how ToIP-based systems fit with existing systems. The patterns should work for either a DIDComm-based stack or a KERI-based stack. Both can produce a "trustworthy relationship with the unknown".
  • Vlad suggested that we might want to introduce the idea of "best patterns".
  • Bart shared this: https://engineering.atspotify.com/2020/08/how-we-use-golden-paths-to-solve-fragmentation-in-our-software-ecosystem/
  • Drummond shared that as we finish the storyline deck with all our requirements, we should engage in a dialog with both the DIDComm community and the KERI community to get their input and feedback and see what each can contribute.

Wenjing will present Part 2 of the presentation he started last week about a reference architecture for the stack.

• Wenjing made the point about "the layer you cannot skip". With the TCP/IP stack, that is the IP layer. With the ToIP stack, that is Layer 2.
• Our stack needs to cover compute, store, networking — Wenjing has put these all in Layer 1. The requirements for each one needs to be specified.
• Wenjing changed the Layer 1 name to "primitives".
• Each one of these L1 services can be local or in the cloud. At one end, all can be local, and at the other end, they could all be in the cloud.
• Bart said "I like the approach suggested here: first talk fit, then later talk function. It helps frame what type of problem is being solved (reference) for engineers, and then goes into details about the options (stack)"
• Wenjing's new slide is #14 below
• His final two points:
  • The reference architecture picture should identify the different areas where we need to specify
  • We may also identify other key roles that need to be identified so we can decompose them
• Bart: "my key takeaway: all of this is about framing it inside a picture of trustworthy systems, rather than having the picture be defined by technology X or Y"

APAC Discussion:

• We had a longer discussion of Wenjing's slide #14 and its role in our stack.
• One topic there was wide agreement about is that the terms "wallet" and "agent" are not precise enough for what we will need in the ToIP Technology Architecture Specification.
• We also talked about his new slide #15 below that "zooms in" to talk about specific functionality of Layer 1 and Layer 2.
• Drummond suggested that the ToIP Technology Architecture Specification actually needs several "views" of the stack:
  • Protocol view
  • Reference architecture view
  • Data structures & functional view

We discussed the blog post series on the EU eIDAS 2.0 framework that last week we agreed to start.

• Antti felt that we need to take the larger context of how the EU framework will need to work with the rest of the world.
• So he proposes a multi-part approach to the blog post that explains the approach we recommend that explains how ToIP can proceed in parallel to the EU approach.
• So his recommendation is to create a proposal that highlights the issues and proposes how 

• Review decisions/action items
• Planning for next meeting 

• Drummond will not be able to attend next week's meetings due to travel.