• ACTION: Wenjing will add a defined message to the relationship formation stage which can be used to notify another party of a key state change.
• ACTION: Drummond Reed to prepare a first draft of a blog post announcing the TSP Implementers Draft by our April 3 meeting.
• ACTION: Judith Fleenor to seek a ToIP Steering Committee policy decision about whether to encourage (or require) ToIP Foundation code projects to be limited to test/conformance suites.

Darrell O'Donnell 

There is currently a limitation in Spec-Up about what external specifications it can reference with its tagging feature. Darrell has a plan for addressing that.

ACTION: Darrell O'Donnell to create a Spec-Up issue concerning external specifications.

Drummond Reed 

We had a good discussion about the proposed 3rd generation ToIP stack diagram shown in screenshots #1, #2, and #3 below. Those are from this slide deck spearheaded by John Phillips. Our main takeaways were:

1. Drummond Reed explained that the "stack diagram" has now evolved into the ToIP Trust Canvas. Screenshot #1 shows the trust canvas view in the simplest, most abstract form.
2. The "glossy" version combines an illustration of key components in four-layer technology protocol stack with the governance process model. It also separates out the overall ToIP model from an ecosystem instance.

Tim Bouma said that he felt this diagram would be very effective when used by management consultants to explain the heart of the ToIP model.

Drummond Reed emphasized that the "glossy" version shown should, whenever possible, be accompanied by other slides that introduce the basic idea of the ToIP Trust Canvas, show the simple structure first, then the glossy "full example", and then show how multiple digital trust ecosystems can interconnect and interdepend. He also suggested that, if possible, the ToIP Foundation should create a full "Guide to the ToIP Trust Canvas" as a slide deck, a document, a branch of our website, and a webinar (or set of webinars).

Wenjing Chu Sam Smith 

Wenjing showed us the current version, which is the first relatively complete draft in Spec-Up: 

https://github.com/trustoverip/tswg-tsp-specification/blob/tsp-draft-0-1/spec/spec.md

He reviewed the different open issues (see the NA/EU meeting recording for his tour). See screenshot #4 below.

Highest priority for review by TSPTF members:

1. The focus is moving to very precise specification language, so check to make sure it is clear.
2. Try to pick really key points that would be important to implementers.
3. Any areas that you have questions about as an implementer.

APAC:

Wenjing did an extensive review of the entire table-of-contents of the spec, leading to several excellent discussions reinforcing the overall structure and terminology.

We discussed the dependency of the TSP spec on the CESR spec. We were comfortable that they could all be contained in Section 9, as illustrated by Darrell O'Donnell's diagram below:

After Wenjing completed his review of the entire TOC, on the APAC call we agreed to merge his PR into Main so that the Working Draft now fully renders in GitHub Pages. The rendered version is here:

https://trustoverip.github.io/tswg-tsp-specification/

All the TSPTF members on both call extended their thanks and congratulations to Wenjing for all of his hard and very elegant and excellent work in moving the whole spec to Spec-Up. This puts us solidly in a position to publish the Implementers Draft before IIW.

ACTION: ALL TSPTF MEMBERS to begin reviewing the proto-Implementers Draft at https://trustoverip.github.io/tswg-tsp-specification/ and post any issues they believe should be addressed before we publish this as an Implementers Draft.

Drummond is still working on the blog post—it will be ready for review at next week's meeting.

In the APAC meeting, we discuss the following key points for the blog post:

• What the protocol offers:
  • Interoperability across transported payloads
  • Interoperability between different identifiers
  • Security properties: the Big 3
• CESR encoding option
• Which VIDs?
• Which Internet transport bindings?
• The spanning layer protocol is being defined to extend and evolve with higher level protocols (trust tasks). Those take a lot of the challenges of interoperability and move them up to a higher level, making them much easier to interoperate.
• "This is the protocol that all other protocols can be based on."
• Answer the question about why not TLS or HTTPS.
  • We need to be able to answer that question.
  • Not a client/server protocol.

• ACTION: Drummond Reed to prepare a first draft of a blog post announcing the TSP Implementers Draft by our April 3 meeting.