Any news and updates of general interest to CTWG members

• Rieks Joosten will not be able to spend as much time on ToIP in general as he did last year. He continues to be active in CTWG and the dev-team though.
• Drummond Reed has also been tasked with some major projects at Gen, which will also impact his time. He hopes it will affect CTWG involvement. Hopefully it will also lead to more Gen resources contributing to ToIP.

•  ACTION: Drummond Reed to check with Judith Fleenor about converting  "Decentralized SSI Governance" into a ToIP template to publish it as a white paper.
•  ACTION: Brian Richter will email Judith Fleenor a current copy of the TEv2 SOW.
•  ACTION: Brian Richter to help Nicky Hickman produce a glossary document from the HXWG terms wiki by working around the EasyCLA manually.
  •  Brian reported that the EasyCLA issue is proving to be more difficult than anticipated. Brian does not have direct access to the LF EasyCLA team.
•  ACTION: Drummond Reed to add a status report on the Mental Models Task Force proposal to the agenda of the next meeting.

Rieks Joosten Brian Richter 

• Brian has been working on the EasyCLA problem, which is that a github Action cannot merge to the main/master branch because (as I understand it), the 'account' of that action (obviously) hasn't signed a CLA (as human contributors would have), and therefor doesn't allow it to merge stuff. This is a blocking issue, not just for terminology repo's, but for any repo that uses github Actions to do things when merging to main/master. 
• The dev-team decided not to waste time on this generic issue, but instead ask Drummond Reed and/or Judith Fleenor to arrange for this issue to get sorted on TOIP scale, as other WGs/TFs are bound to suffer from this as well. In the meantime, we will be working with personal repo's for the further development, testing and documenting of the tools. This might turn out to be a nice exercise to see how the tools would fit in other contexts as well.
• The TRRT is ready as a Minimal Viable Product. It lacks some of the generic features. For example, one TRRT-run will only resolve TermRefs from a single MRG. For now that may not pose serious problems, and there are various ways to work around this. The TRRT will first be integrated in the eSSIF-Lab repo to see how/if things work. Also, documentation needs to be written for curators so that they can use/call the tool.
• Since the last two meetings ended well within 30 mins, we have decided to reschedule the meetings to start half an hour later.

Neil Thomson Drummond Reed 

Rieks Joosten Nicky Hickman 

What is our current thinking?

• Neil Thomson observed that it is important to consider all the players involved with the flow to make a trust decision. There can be as many as 6 different levels that need to be clarified in order to make a complete trust decision based on data from a trust registry.
• Judith Fleenor suggested that if the mental models work was attached to the Trust Registry Task Force, it would make it more concrete. 
  • Drummond very much agreed.
  • Neil also agreed, in particular that it would understand what trust registries have in common.
• Rieks Joosten observed that his recent work with data spaces is showing him that multiple groups are doing similar work on similar spaces. They are using lots of terms, but not really working hard on defining them. So the problem is how to align all these ways of thinking — and how concepts were being named.
  • His personal view is that if there were a mental model of the space, it would be much easier to see where these communities agree and disagree.
  • But we have not yet established a way of working that produces such an outcome.
  • For the Trust Registry Task Force, the question is what they would need to support their specification.
  • The same needs to happen for the Technology Architecture Task Force.
  • Is the goal we are aiming for too high to reach?
• Judith said the one place it's been asked for is the Trust Registry Task Force, so they may be open to it.
• Rieks agreed that it doesn't really make sense to start such an effort unless:
  1. You know what the deliverable is going to be (should be auditable)
  2. You should know who is actually going to use it. It's not just an abstract "audience", but specific stakeholders.
  3. What are these specific stakeholders actually going to do with the document? The content should be used by those stakeholders to accomplish the task they have.
• Drummond said he believes that the Trust Registry Task Force fits that bill:
  • A mental model with deep support for glossary terms that will be used in the ToIP Trust Registry Protocol Specification.
  • It will be used by the task force members to draft the specification and resolve ambiguities about the terms used.
• Drummond asked how we would suggest the TRTF proceed if they were interested.
  • Rieks suggested the following:
    1. Start writing the spec and mark every term that needs a definition.
    2. Document each noted term by supplying a first criterion by which the members of the task force can determine if an instance is an example of the term. For example, throw a number of use cases at it, and see if the criterion works. If it doesn't, find the criterion that does.
    3. Document these discussions so you end up with a little document for each term that not only provides a definition, but gives readers an understanding of the criterion that were used and why.
    4. Once you have agreement, you return to the specification document and revise it to incorporate the terms based on the the new definitions and criteria.
    5. When you find that the terms all relate to each other in a clear way, then you have a mental model you can draw and document.
  • The result is a much higher quality document.
• Neil had some reservations about what he believes the TATF has an appetite for.
• Rieks shared screenshot #1 (below) to show an example of a mental model for data sharing.
  • It shows two parties producing data within an data sharing ecosystem.
  • The policies of each party are all business-level logic and policies about who is producing what data under what terms for what consuming parties. There are not implementation-layer policies at all.
  • Down at the operations layer, that's where the technology implementation policies are implemented, such as data formats, cryptographic verifiability, protocols, polling, etc.
  • In Rieks view, this three-layer model works very well for many different governance models.
    • Question from Neil Thomson - Looking for the difference behind the following sub-policy types listed in the Policies Management layer Polices (blue folder) elements:

• • • • provisioning - from a telecom perspective - provisioning has a very specific meaning
      • requesting
      • infra-use