2022-08-11 TATF Meeting Notes

Owned by Drummond Reed
Last updated: Aug 18, 2022
8 min read

Meeting Date & Time

  •   This Task Force holds TWO meetings weekly every Thursday at the following times (to cover global time zones):
    • NA/EU 07:00-8:00 PT / 14:00-15:00 UTC 
    • APAC 18:00-19:00 PT / 01:00-02:00 UTC

Zoom Meeting Links / Recordings

Attendees

NA/EU Meeting

APAC Meeting

Main Goals of this Meeting

For the ToIP Technology Architecture Specification: 1) Review additional diagrams proposed by Darrell O'Donnell, 2) Decide about numbering & compiling normative requirements, 3) Review mental model of system types, 4) Next steps for completing the first Public Review Draft.

Agenda Items and Notes (including all relevant links)

TimeAgenda ItemLeadNotes
3 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:
5 minAnnouncementsAllUpdates of general interest to TATF members.
2 minReview of previous action itemsChairs

The notes from the previous meeting (2022-08-03) were not clear about explicit action items.

  • ACTION: Neil Thomson Create a TATF Project Management document to describe details of issue management across Tech Arch Spec and related deliverables
  • ACTION: ALL MEMBERS to continue to review sections 7 through 11 of the ToIP Technology Architecture Specification to add any final comments or suggestions
  • ACTION: Neil Thomson - proposed communication used by EndPoint Systems and Supporting Systems, on-node Support System inter-communication and cross-network interaction within a Support System - see Proposal on Supporting Systems Communication  
  • ACTION: Drummond Reed to raise an GitHub on this topic [[DO: WHAT TOPIC??]] as it will require more in-depth discussion that is feasible in Google docs (and because we are now trying to move all new issues to GitHub).
  • ACTION: Neil Thomson update the TATF "design principles" to include "detailing" of Use cases from Tech Arch through test cases.
  • ACTION: Darrell O'Donnell to suggest a replacement for Figure 2 (development progression)
  • ACTION: All to review Jo's model (below) for future discussion

ToIP Technology Architecture Spec Topics

Discussion of progress on the working draft of the ToIP Technology Architecture Specification:

15 minsAdditional diagramsDrummond Reed 

From Darrell O'Donnell in the TSWG Slack channel:

I won’t likely make the Thursday meeting. Business has me messing with too much of the time I am supposed to be spending with friends that flew in from out of town.I suggest reviewing the two slides here: https://docs.google.com/presentation/d/1skHbfJqXaX8er8iUzisNWWnFCMp7bv2ZjKmsq4GXyeA/edit#slide=id.gf9dcc57430_0_4

    • First slide moves Cryptography, Compute, Storage, and Communications under Layer 1 - we aren’t doing ToIP-specific things there - we use them as would any other system.
    • Second slide may fit an appendix (and needs aligning) for telling the story of “How does XXXXXX compare with the ToIP 4-Layer Stack?”

Darrell's first slide is copied as screenshot #1 below and his second slide is screenshot #2.

Discussion: First slide could be updated with a vertical side bar that crosses layers for common ToIP support components used by all layers.

Scott Perry - need to get more detail. Registries are confusing as they are also needed at layer 4. Replace "registries" with "resolver(s)". Trust spanning is perhaps the right term - suggest interop layer

Allan Thomson - need the sidebar for common ToIP components/services. The world hasn't moved to DIDCOMM - what are the preferred protocols and channels for Layer 2. Change this to a set of (Interop) requirements for which DIDComm is the ToIP contribution. Need a diagram version that maps to OIDC (to provide a (conceptual) bridge)

  • (Drummond Reed was not on the meeting yet due to Internet issues but later in the meeting noted that this was the purpose of Darrell's second diagram. See discussion below.)

Tim Bouma commented that DIDComm is a "heavy" solution to interop communications. There are several specs that are provided as "full-featured", which may be overkill for initial implementation and acceptance (and actually required functionality). Decentralized identifiers and Verifiable Credentials are other examples. The trend has been to "overspecify".

Drummond Reed said it would not only be a mistake to — at this point in time — specify DIDComm as the only Layer 2 trust spanning protocol, not only because there is not yet consensus on that, but because we put specifying explicit protocols out of scope for this architecture spec. That's the job of component specs.

ACTION: Drummond Reed to update Darrell O'Donnell's proposed diagram to incorporate the feedback from this meeting and then figure out where it best belongs in the next draft.

Neil Thomson suggested we want specifications for each layer expressed as requirements, not solutions and certainly not specific technologies.

Drummond Reed agreed with Neil — we need to be designing the right architecture and designing component specifications to meet those requirements.

Tim Bouma agreed that it is the need for a trust spanning protocol (or "hourglass protocol") that will "capture the imagination" of readers and help us gain the focus and support we need to complete the work of developing and/or assembling the component specifications. The way he expressed our ultimate goal is: "Today we don't think about how we're communicating (over the Internet); tomorrow we won't have to think about how those communications are trusted."

thomsona pointed out that it is not necessarily the purity or beauty of an architecture that wins in adoption of a "stack", but about how easy it is to develop on. He gave a number of examples including TCP/IP. So we need to focus on what is going to use the trust spanning protocol, not the protocol itself.

On Darrell's second diagram (screenshot #2 below), there was consensus on the following decision:

DECISION: We will add a "Current State Mapping" appendix to the ToIP Technology Architecture Specification whose purpose is to provide a "snapshot" of how existing protocols, APIs, and technologies map into the ToIP technology architecture.

ACTION: Drummond Reed to include a first draft of the "Current State Mapping" appendix in the next Working Draft. 

APAC:

  • Neil Thomson proposed to use a three-dimensional "cube" diagram that shows how to tie the different views together. See his sketch of such a diagram as screenshot #4 below.
  • Neil and Jo both noted our previous discussions about Wenjing's diagrams being focused on comms protocols and not some of the other views. Both are needed.
  • ACTION: Neil Thomson will create a first draft of a proposed three-dimensional "cube" diagram that can serve as an anchor to tie the different views of the stack.
  • sankarshan asked "Is there a way we can have a repository of these different views of ToIP architecture and stack? It will be valuable now and also when there is a body of work to examine as archive."
    • Drummond responded that the repository for ALL the diagrams we have been creating are in one Google Slides document.
    • Sankarshan said that these should be moved to a GitHub repository for both archiving and review.
    • There was consensus on that point.
  • Drummond Reed shared an update (screenshot #3) to Darrell's proposed stack diagram (screenshot #1) that incorporated several suggestion from the NA/EU call.
  • Jo Spencer shared that the current set of diagrams in the spec were fully focused on the interaction patterns, and didn't really talk about the overall architecture of the stack.
    • Jo shared several other diagrams, including screenshot #5 below, that can help clarify the key terms. See the "mental model of system types" topic below.

We then talked about the proposed new appendix and how important it was to carry the message about interoperability with existing protocols.

10 minsRequirements numbering and appendixDrummond Reed 

The notes of the last meeting indicated a discussion of an approach where all normative requirements are numbered throughout the spec and then compiled in a table in an appendix. Darrell O'Donnell and Drummond Reed discussed this when Drummond returned from vacation and before Darrell left on vacation.

DECISION: We will number all normative requirements in the ToIP Technology Architecture Specification and compile them into a table in an appendix, including cross-links in both directions.

ACTION: Drummond Reed to implement the requirements numbering/compilation decision in the next Working Draft.

10 minsMental model of system types

Drummond Reed Jo Spencer 

Drummond was on vacation for the last two meetings but saw the notes from the last meeting including the discussion of the mental model of system types. This appeared helpful but still appears to have some issues. Can we close completely on definitions of:

  • Endpoint Systems
  • Intermediate Systems (basically routing components)
  • Supporting Systems (need more definition about what they are and how they communicate, i.e., how they are different. Also, what are the requirements?)

APAC:

Jo shared a diagram (no screenshot available) that can help clarify these key terms. Drummond and Neil provided some feedback that Jo incorporated.

ACTION: Jo Spencer will move a copy of his slide deck of 3 diagrams to the ToIP Google Drive for the TATF.

ACTION: Drummond Reed to incorporate Jo's "systems mental model" diagram and explanation into the next Working Draft.

10 minsNext steps on the Working DraftDrummond Reed 

With Darrell O'Donnell and Wenjing Chu both out on vacation this week and next, Drummond proposes to:

  1. Produce another draft of the Google doc incorporating all these action items before next week's meeting (Aug 18).
  2. Review that draft at next week's meeting.
  3. Incorporate any feedback on that draft to produce as clean a draft as possible for the following meeting (Aug 25).
  4. Review that draft with Darrell and Wenjing back.
  5. Move everything to GitHub and prepare the first Public Review Draft to present at the ToIP Summit 2022 on Sept 14.
5 mins
  • Review decisions/action items
  • Planning for next meeting 
Chairs

Screenshots/Diagrams (numbered for reference in notes above)

#1

#2

#3

#4

#5


Decisions

  • DECISION: We will number all normative requirements in the ToIP Technology Architecture Specification and compile them into a table in an appendix, including cross-links in both directions.
  • DECISION: We will add a "Current State Mapping" appendix to the ToIP Technology Architecture Specification whose purpose is to provide a "snapshot" of how existing protocols, APIs, and technologies map into the ToIP technology architecture.

Action Items

  • ACTION: Drummond Reed to add the ToIP Google Drive URL to the TATF Meeting Page template.

  • ACTION: Drummond Reed to implement the requirements numbering/compilation decision in the next Working Draft.

  • ACTION: Drummond Reed to incorporate Jo's "systems mental model" diagram and explanation into the next Working Draft.

  • ACTION: Drummond Reed to include a first draft of the "Current State Mapping" appendix in the next Working Draft.
  • ACTION: Drummond Reed to update Darrell O'Donnell's proposed diagram per the feedback in the 2022-08-11 TATF meetings and then figure out where it best belongs in the next draft.
  • ACTION: Neil Thomson to create a first draft of a proposed three-dimensional "cube" diagram that can serve as an anchor to tie the different views of the stack.
  • ACTION: Drummond Reed to incorporate Neil's diagram into the next Working Draft.

  • ACTION: Jo Spencer to move a copy of his slide deck of 3 diagrams to the ToIP Google Drive for the TATF.