Time

Agenda Item

Lead

Notes

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 min

Announcements

All

Updates of general interest to TATF members.

2 min

Review of previous action items

Chairs

SPEC REVIEW

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

• Google Doc version 

• GitHub Markdown version

• GitHub issues list

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 (Deactivated) 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 mins

Section 5: Use Cases

@Neil 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 mins

Section 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 mins

Section 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.