• Start recording
• Welcome & antitrust notice
• New member introductions
• 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:

In the past few weeks we've split the work into a series of documents:

• 1. Intro to Governance Development Kit
• 2. ToIP Implementation Guide
• 3. Governance Architecture Requirements
• 4. Governance use cases to be fused with Scott and Savita's work

We can all together work together to improve the list of components.

Anita asks - should we align the component list to the 4-layer stack? The picture of the stack is very familiar. (https://trustoverip.org/wp-content/uploads/trust-over-ip-technology-governance-stack-768x495.jpg)

Savita: We can look at diagrams from the Trust Registry slack channel because they have been creating figures that may be useful for assigning components.

John: we should be cautious in that our component list will always be incomplete, so we should look for a generally applicable approach to governance for all/any components rather than specific governance definitions for all possible components.

Scott: the documents are good direction for developing future work. Now we can work on filling in the blanks. Scott asks "what are the must statements" for components etc. within the stack. Maybe even we can get to the should statements. This governance guidance is needed for governance bodies to start writing from.

Scott also emphasising the need to drive towards requirements, not to get too focused on many use cases but perhaps to elaborate a few in detail so that we focus on requirements.

Scott suggesting that we might use the museum pass use case as the example to drive governance requirement discovery/documentation.

Alex emphasising that we need to be careful to include only the generic requirements from the use case discussion rather than use case specific requirements.

Neil: based on work of trust registry - doesn't matter so much where the components sit in the stack, but what is the flow of the use case. The requirements may also change depending on the lifecycle of the trust (trust establishment vs trust maintenance).

John: echos caution in using use cases to establish requirements. Need for a mental model for governance so that we can provide the meaning for the terms and actions that we are describing.

Scott echoed that a mental model, such as those that Rieks Joostetn 

Alex and John: caution also with mental models that may not be informative for implementers.

John proposed that the combination of a governance mental model, governance requirements, and governance use cases provides the detail that implementors require.

Savita: what are the targets of governance that are trustworthy.

Scott: ESSIF governance mental model: https://essif-lab.pages.grnet.gr/framework/docs/terms/pattern-governance-and-management John: adds that the problems they are trying to solve may be different.

Jo: interoperability is the responsibility of the governance body.

Proposal from Scott that we work on the draft table of contents for the documents so that we can identify/decide the areas that we want to / need to focus on.

• Review decisions/action items
• Planning for next meeting