2022-07-21 TATF Meeting Notes

Meeting Date & Time

  •   This Task Force holds TWO meetings weekly on Thursdays 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 Recordings

Attendees

NA/EU Meeting

APAC Meeting

Main Goals of this Meeting

For the ToIP Technology Architecture Specification, 1) Report on Section 5: Use Cases, 2) Reach closure on Section 6: Reference Architecture Overview, 3) Close as many comments and make as many decisions as possible about Section 7: Endpoint Systems and the Layered Stack, 4) Agree on plan for the next two weeks.

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

SPEC REVIEW

The following agenda items all focus on progress on the working draft of the ToIP Technology Architecture Specification:

APAC:

  • Neil Thomson brought up a general point about the tension between the "ideal" stack and a "practical" stack.
    • For example, currently it is proposed that Endpoint Systems must have autonomous identifiers, but they could do authentic identifiers.
    • So the difference between the minimum standard and the preferred would be important.
    • An example is the use of OpenID Connect, which does not use autonomous identifiers.
    • Daniel Bachenheimer brought up the example of the European Digital Identity Wallet requirements for a wallet to be able to bind an identity to a provisioned device ("device binding") so that it can used to authenticate at a High level of assurance.
    • Judith Fleenor clarified that the device binding is one of the two factors needed to achieve LOA High — that's the role of the biometrics.
    • Drummond Reed suggested that there may be a better term to describe the class of identifiers that provide the properties we need at ToIP Layer 2. 
    • Dima Postnikov  shared that the LOA question is outside of the actual sharing protocol, but can be communicated between the parties. There is no difference between how OIDC would communicate the LOA for authentication and how the ToIP protocols would do it. So the means of achieving LOA should be part of the protocol design.
    • Drummond Reed suggested that the term that might be able to classify the type of identifiers that are acceptable for the ToIP stack is verifiable identifiers.
    • Neil Thomson also asked about supporting systems and where they fit, and how they talk to each other.
5 minsSection 5: Use CasesNeil Thomson 

Per the note in the spec:

The content for this section has been temporarily moved to another Google doc: ToIP Use Case Candidates and Catalog. Content for that document is now being curated by the ToIP Ecosystem Foundry Working Group (EFWG). They are developing a catalog of use cases which with then be used to produce: a) a final one-page table of use cases to be included in this section, and b) a small set of fully fleshed-out use cases (written in greater detail) to be published in a new EFWG deliverable called Canonical Use Cases for ToIP.

  • Neil explained that the Ecosystem Foundry WG is stewarding the collection of use cases, but that all ToIP WGs and members are invited to contribute.
  • The intent is that you put in a candidate use case by adding a role to the table.
  • There is a new row in the table for how the use case is distinguished from the others.
  • thomsona wanted to make sure there was a clear way to resolve questions or disagreements about whether a use case is validly in scope for the ToIP architecture.
  • Drummond Reed clarified that a representative list selected by us (the TATF) and curated by us and brought back into our document.
  • The Ecosystem Foundry WG are also doing separate work on use cases and have their own use case template. They are also planning to produce a separate deliverable consisting of 3-4 use cases that are fully documented and can be referenced by other ToIP deliverables.

APAC:

  • Neil Thomson suggested that we ask people to pair up to review and improve use cases as he has found this "paired programming" approach very successful.
10 minsSection 6: Reference Architecture Overview

LAST CALL: Resolve any final questions or comments about this section.

  • See Wenjing Chu's proposed text at the end.
    • This proposed revision was accepted.

APAC:

  • We were able to agree on reducing the contents of the table to a smaller number of examples, thus resolving all the suggestions.
  • The new issue that came up was around the definition of the term authenticity.
    • Daniel Bachenheimer pointed out that the places we mention it in this section seem to also call for citing the relevance of integrity.
    • Neil Thomson said that we were defining authenticity as including integrity.
    • Both Dan and Drummond Reed were uncomfortable with this and suggested we needed to revisit the wisdom of redefining such a commonly used cybersecurity term.
    • ACTION: Drummond Reed to raise an GitHub on this 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).
25 minsSection 7: Endpoint Systems and the Layered Stack

Key topics:

  • Formatting for requirement statements.
  • Defined terms.
  • 7.2: Proposal to use the term "Trust Support Functions".
  • 7.3: Proposal to use the term "Trust Spanning protocol".
  • Many other comments.
5 mins
  • Review decisions/action items
  • Planning for next meeting 
Chairs

Plan for the coming week:

  • Drummond Reed is flying to San Jose on Monday morning to meet in person with Wenjing Chu and thomsona for two afternoon writing sessions to see if they can "push through" on the spec.
  • The goal is to see if we can come as close as possible to consensus on the text, diagrams, terms, and requirements statements in the remaining sections.
  • The proposed revisions will be posted by next Wednesday for review on next Thursday's call.
  • After next Thursday's call, hopefully we will be ready to convert all the remaining sections to Markdown in our GitHub repo and transition to working all remaining issues via GitHub issues and revisions via pull requests.
  • Drummond will be on vacation from July 28 through Aug 7, so he will miss the next two meetings. (He will be back for the Aug 11, 18, and 25 meetings.)
  • A proposed goal is to send out a Call for Community Review to the ToIP All-Member mailing list after our Aug 11 meeting to get a few weeks of ToIP community review.
  • By the end of August we should have the Public Review Draft ready to announce/present at the ToIP Mini-Summit in Dublin on Sept 14.

Decisions

  • None

Action Items

  • 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: Drummond Reed to raise an GitHub on this 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).