• 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:

• ACTION: If you have any feedback on issues #40, #46 & #49 — roles, pull requests (PRs) and the version publication process — please go in and comment. If you have any questions, ask them in the #tswg-tech-arch-tf Slack channel.
• ACTION: ALL TATF members need to read the EasyCLA process document and decide on the CLA manager assignment for your organization in order to continue to make contributions to the TAS. You can also set it up to provide wildcard support for all representatives of your org (based on your email domain). See Elisa Trevino for access/help.
• ACTION: Darrell O'Donnell to propose another variant of Figure 4 as a candidate for the "full stack" diagram discussed in issue #31. DONE.
• ACTION: Allan Thomson to propose a simpler diagram to replace the current Figure 4 in section 6.2 as discussed in issue #31.
• ACTION: Jo Spencer to noodle on some diagrams that more clearly define the borders of the "sphere of influence" of the ToIP stack.
• ACTION: Drummond Reed to begin a draft of a blog post announcing release of the Public Review Draft of the TAS.

Discussion of progress on the working draft of the ToIP Technology Architecture Specification (TAS). Links to relevant documents and diagrams:

• TAS GitHub Markdown version
• TAS GitHub Issues
• TAS GitHub Discussions
• TAS Source Diagrams (Google Slides) <== SOURCE DIAGRAMS used in the TAS
• ToIP Protocol Stack Diagrams (Google Slides) <== All of all our past diagrams (some of which have been copied to TAS Source Diagrams)
• TAS WORKING DRAFT 03 Google doc version <== REFERENCE ONLY — NO LONGER ACTIVE
• TAS OLD WORKING DRAFT 02 Google Doc version <== REFERENCE ONLY — NO LONGER ACTIVE
• Evolution of the ToIP Stack <== NEW proposed companion document
• TATF Google Drive Folder <== WHERE ALL OF THE ABOVE may be found

Two of the four assigned editors have approved this PR. Can we merge it?

Description: Initial governance files of CODEOWNERS, CONTRIBUTING.md, and GOVERNANCE.md. Related to issues:

#40
#39
#38
#46

Review Allan's proposed new version of Figure 4.

See this evolution of the previous version.

This paragraph in Neil’s writeup goes to the heart of it:

Dan Bachenheimer points out that many readers with security backgrounds will expect to see integrity listed alongside authenticity because they are considered separate security properties. For example, a message could have been sent by an authentic sender, but tampered with in transit so its integrity is lost.

Sam’s first point was very simple: if the message was “tampered with it transit”, then it is no longer from the authentic sender. At that point it is from the attacker (who of course will endeaver to make it the message still look like it is from the authentic sender).

Sam put it to me this way:

There is no concept of data transmission over the Internet where you can establish the authenticity of the data — secure attribution to a source — without having confirmed the integrity of the data.

So the resolution seems simple: the definition of “authenticity” when it comes to the ToIP stack and the Layer 2 Trust Spanning Protocol can essentially be:

A communication is authentic at ToIP Layer 2 when the receiver can cryptographically verify that it has been digitally signed by the private key bound to the sender’s identifier. Because this form of authenticity is conveyed via a digital signature over a body of content, by definition that digital signature is only valid if the body of content has not been tampered with in transmission. Therefore this form of authenticity inherently includes integrity.

If we agree on this point, then all we need to discuss is the PR that is needed to actually close the issue.

• Review decisions/action items
• Planning for next meeting