Drummond Reed 

The transition to LFDT will take place over the next few months. As part of this transition, we will also be refactoring some WGs and TFs.

Judith Fleenor explained that it is financially advantageous for the ToIP Foundation, as a JDF project, to be a project under the LFDT umbrella project. However it does mean adjusting some of our toolset, e.g., moving from Slack to Discord.

This also affords an opportunity to do some refactoring of WGs and TFs. One is the formation of a new WG for ACDC and KERI. That process is underway with the ACDC TF and the ToIP SC.

Second is a transition in TSWG leadership.

Third is the X5VTF transition.

Fourth is a possible IPR licensing change. Sam Smith is ready to have a special meeting on that topic.

https://github.com/openwallet-foundation-labs/tsp.

We mentioned that the project may be renamed "Teaspoon".

Wenjing said that the first release ("0.5") should be ready by Sept.

The code includes visual examples that show an Alice-and-Bob example that helps explain the messages, encoding, etc. More power is available in the CLI.

Wenjing would be happy to go through a demo in a longer session.

The project has implemented several prototype DIDs. Private: DID peer. Public: did:web and did:tdw. The SDK being developed will enable support of stronger verification and dynamic appraisal.

There is a call for others to contribute the types of DIDs that they would like to see supported in the first release. Also starting integrations.

Wenjing also mentioned that DIF has a China digital identity forum that have invited Wenjing to share more information with them about TSP. Wenjing has written an introduction in Chinese and a video to go with it. There is a lot of activity in blockchains and IoT, but also in digital identity. Wenjing is very interested to see how TSP adoption might work there.

ACTION: Drummond Reed to schedule Wenjing Chu to give a OWF TSP project demo on the agenda for the next meeting on Sept 4th. 

We also agreed that having information about the APIs and SDKs ready to share at IIW would be very helpful.

Sam Smith shared that the KERI Python code now supports all of the test codes.

ACTION: Wenjing Chu and Sam Smith to get together offline to work on alignment of the CESR code points.

Continue the discussion from the last meeting (per action item above).

Drummond explained that Charles Lanahan was not here today, but he was asking questions about trust tasks at the last meeting.

Wenjing Chu suggested that the place to start is defining what is a trust task and why would developers need trust task protocols.

He said that two common trust tasks are being able to verify a timestamp or a location. It turns out that both of these are hard challenges. Dedicated protocols have been developed for each that must build the entire "stack" because the fundamental task of establishing the trust necessary to rely on the timestamp or location data is the hard part.

So those two relatively simple trust tasks are good examples of how what it otherwise a complex task becomes so much simpler on top of TSP because the majority of the problem is addressed at the TSP layer. Therefore the trust task protocol is much easier.

Wenjing explained that his introduction paper goes into this much more thoroughly. Once you see the TSP layer in this light, it is easier to see different trust tasks.

Wenjing said that the other TF he co-chairs, the AI & Metaverse TF, can define a trust task for sharing AI information with strong provenance. And of course VC exchange (issuance and presentation) are trust tasks.

Sam Smith agrees with that definition of trust tasks. He points out that the TSP doesn't provide any more security than the VIDs being used with the TSP. He is concerned that there may be a misconception that the TSP will add security and metadata privacy if you start with an insecure DID. He wants to avoid the TSP becoming "security theatre".

Wenjing agreed that TSP is a "trust spanning protocol" and if there is not trust to start, there is no trust to span. So VIDs are really the basis of the trust. The protocol does not create new trust, rather it helps the parties using the protocol to establish a connection between VIDs that is as secure and private as those VIDs can support.

Darrell O'Donnell said it's also important to incorporate appraisability, so that there is real-time feedback on the actual usage of the protocol. 

Neil Thomson "Concerns w respect to the "stack" including the VID selected - trustworthyness of a trust task depends on the (component) stack and the protocol(s). Suggests that any static Risk Assessment includes looking for the "weakest link"."

Sam Smith mentioned that XMPP adoption with Omemeo is increasing now because Omemo includes support for the Signal protocol. So now attacks will be aimed at the identifier level instead of at the protocol level. So if we don't elevate the minimal level for VIDs using TSP, then folks will just use XMPP since it is already established.

XMPP supports plug-ins, both at the transport level and the application level. The application-level plug-ins are the equivalent of our trust tasks.

Judith Fleenor "The thoughts that Sam just stated, is where I think Charle’s comments about Trust Task came from.  Why Trust Tasks over TSP when there are other things that are already being used to solve the same issues.  What’s the advantage?"

Sam explained that in the health industry, they are already using this secure version of XMPP with app plug-ins. However they have not addressed the strength of their VIDs. The one thing they can't do is security at the identifier layer. Sam mentioned that there was a recent hack of 2.5B credit records that reveal a huge amount of personal information.