Meeting Date

19 Jun 2023 The CTWG meets bi-weekly on Mondays at 10:00-11:00 PT / 17:00-18:00 UTC. See the ToIP Calendar for the full schedule.

Zoom Meeting Recording

https://zoom.us/rec/share/nnWDDc4CF9rG4W_2BoXc7BA-pn_cbykM7EfII2sfwJCa9fkVid8jrsU-qYw8uJ9T.eh4QfyomKQYX7voP

Attendees

Agenda Items and Notes (including all relevant links)

Time	Agenda Item	Lead	Notes
3 min	Start recording Welcome & antitrust notice Introduction of new members Agenda review	Chairs	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: None.
5 min	General announcements	All	Any news and updates of general interest to CTWG members Neil Thomson is looking at a Trust Establishment workflow. That work at DIF is complete; now we are looking at some ecosystem documents to provide verifiable information about the ecosystem. Henk van Cann introduced their KERI Suite Search Engine (KERISSE). It is a chatbot that uses ChatGPT to answer questions about KERI. It gives some funny answers currently, but it is being trained to give better answers. This is the test site. Neil suggested the same approach could be applied to consent prompts, to explain to an ordinary mortal the real consequences of a consent decision. Henk pointed out that these large language models (LLMs) need to be taught very well. The bigger the body of knowledge that the LLM is trained on, the better the answers. We discussed how this approach might work with mental models. Rieks pointed out that humans can deal with different mental models, such as the way physicists can deal with a model of light as a particle and light as a wave, while this can be much more difficult for AI bots. Henk explained that he is interviewing developers to understand how they consume info about KERI, and those interviews help inform the development of the documentation.
2 min	Review of previous action items	Chairs	ACTION: Judith Fleenor, Henk van Cann, and Andor to develop recommendations for sustainable GitHub maintenance, including definitions of the skills and roles needed and how a ToIP GitHub Support Group should be formed and maintained. Henk has created a draft of this document. NEW: ACTION: Drummond Reed to follow up with Judith Fleenor with regard to Henk's draft document to see how we can address these GitHub issues much more efficiently and effectively, including who/where we might be able to request budget. ACTION: Drummond Reed to check with Andor about acceptance of pull request https://github.com/trustoverip/acdc/pull/3. ACTION: Drummond Reed to put the new TNO Party-Driven Actor model on agenda for the next meeting. ACTION: Drummond Reed to move the ToIP Glossary Workspace Google doc to another location so it can be more widely shared. ACTION: Drummond Reed to review Riek's comments on the ToIP Glossary Workspace and make recommendations about next steps.
10 min	Update on TEv2 progress	Brian Richter Rieks Joosten	Brian Richter couldn't make it to the meetings today (something unfortunate had come up). He has not much to update , and said he'd definitely get to the bugs and HRG this week. TNO will be starting a github or gitlab set of repo's for what will be called TNO Terminology Design. The idea is that it will be the place to go for the methods and tools that TNO is developing (at a slow pace, but nevertheless), and it will all be open source.
30 min	Review of the new TNO Party-Driven Actor model	Rieks Joosten	A visual representation of the TNO Party-Driven Actor models (there are 2 complementary ones) can be found in the section Screenshots/Diagrams. Here's the summary of their purposes: #1 The Party-Driven Actor (PDA) model (external view) explains how terms that are commonly used relate to the concepts of 'Party' and 'Actor' (as in the Parties, Actors and Actions model of eSSIF-Lab). The crucial (new) concept here is the Party-Driven Actor (PDA). The model shows how it is composed of a single party and a single actor, and how it is conceived to execute actions. The figure suggests that 'users' are actually PDAs, and user-accounts should be viewed as PDA-accounts. #2 extends the PDA model with concepts that enable parties to think about how it can get PDAs to do the work related to realizing the party's objectives. This model can serve as an anchor for the parties to design their resource governance and management on, as well as for providing transparency for that, and organize compliance. The figure suggests that in an interaction between parties, it is the PDAs that interact, and it should be possible for one PDA to determine who the party is on whose behalf its peer-PDA is communicating, whether or not it has a particular mandate, and (in anticipation of the revised identity and identifier models) whether or not the PDA's operator (actor) has particular characteristics. The texts associated with these models are currently under a TNO internal review. The text under review is an attachment to this page. Neil Thomson commented: There are two key types of Party-Driven Actors: - Concierge - an Actor/Service which is knowledgeable about available Party Services (from general to highly specialized) - Expert - an Actor/Service (recommended by a Concierge) for a specific service sought by a Party. Drummond Reed asked what is the difference between a Party-Driven Actor and an Agent? Rieks said that depends on what is meant by "agent", since "agent" has so many uses in our space. Drummond felt that this Party-Driven Actor model may in fact be the best definition of "agent" that he has seen. Rieks explained that this Party-Driven Actor (PDA) model means that you should be able to ask a PDA: Who do you work for? Who is your operator? This is particularly important in a decentralized world because PDAs may work for many parties and have many operators. Henk asked about the arrow from the "has onboarded" relation to the PDA. Rieks explained that it was an association class. Henk noted this prompt and response to ChatGPT 4: What is the difference between a mandate and delegation? ChatGPT In the context of governance, management, or politics, both "mandate" and "delegation" involve an authority or power given to a person or group to perform certain tasks or actions. However, the terms carry different implications and are used in distinct circumstances. Mandate: A mandate refers to the authority given to an elected official, a government, an organization, or an individual to act on behalf of others. It typically is derived from an electoral victory where the public has given its consent for a person, party, or group to carry out their proposed policies or actions. For instance, a political party may claim they have a mandate from the voters to implement certain policies. Delegation: Delegation refers to the act of entrusting tasks, responsibilities, or authority to another person or group, typically within an organizational or managerial context. This could be a superior passing down certain tasks to subordinates, or a body like a government or corporation entrusting a smaller group or agency with specific functions. Delegation usually involves a degree of trust that the person or group delegated to will carry out their responsibilities effectively. In essence, a mandate is more about the justification or authority to carry out a certain task, policy, or action, often stemming from a broader public consent. Delegation, on the other hand, is more about the practical process of assigning or entrusting tasks, responsibilities, or authority to others. Rieks explained that the purpose of this model is not just for organizing work and designing systems, but to be able to analyze what when systems interconnect, what questions each can ask of the other. Drummond Reed had two observations: This PDF model is the most accurate definition of “agent” that he has seen. He believes that it would be very beneficial to have a session on this with the Governance Stack Working Group, in particular the Governance Architecture TF.
5 mins	Review decisions/action items Planning for next meeting	Chairs	DECISION: No meeting on July 3 due to the U.S. July 4 holiday. ACTION: Drummond Reed to request Michelle Janata to cancel the July 3 CTWG meeting.

Screenshots/Diagrams (numbered for reference in notes above)

#1 Party-Driven Actor model (external view)

#2 Party-Driven Actor model (internal view)

Decisions

DECISION: No meeting on July 3 due to the U.S. July 4 holiday.

Action Items

ACTION: Drummond Reed to follow up with Judith Fleenor with regard to Henk's draft document to see how we can address these GitHub issues much more efficiently and effectively, including who/where we might be able to request budget.
ACTION: Drummond Reed to move the ToIP Glossary Workspace Google doc to another location so it can be more widely shared.
ACTION: Drummond Reed to review Riek's comments on the ToIP Glossary Workspace and make recommendations about next steps.
ACTION: Drummond Reed to request Michelle Janata to cancel the July 3 CTWG meeting.

Browser not supported