Week 2: Structure and Process (1) 

Hi everyone, welcome to the Week 2 discussions! Thanks to your contribution and participation, we are able to make good progress on the Week 1 topics and beyond. 

Our team is excited to navigate through this very new problem space with you, and we understand that there has been a lot ambiguity which makes our discussions even more challenging.

To help move forward our conversations, we created this collaboration document to

• provide clarity on the Regi-TRUST project and the scope of this consultation;
• capture key points and questions from past discussions and;
• share our team's initial thoughts on the discussion topics in the upcoming weeks.  

We encourage you to read the document and provide thoughts in the SparkBlue discussion forums. And we look forward to speaking to you soon.

Hi all, 

Hope you had a good start of the week! We had a rich and productive discussion at the live session last week. The recording and chat message were posted above. Below are some key points we touched upon. We encourage you to leave further thoughts here and/or build your points for Week 3 on these great discussions:

1. Grievances/Issues/Dispute Resolution: 

How grievances/issues/disputes are accounted for? What would be the role of the different actors involved in the framework right now? Would that be like a new entity altogether? Who could be delegated authority to handle these kinds of grievances between two parties operating within the network?

• Network governing authority needs to define policies for this
• Multiple layers of entities/actors (governing authority, operator,  participants) will likely assume different kinds of responsibilities. 
• Define the requirements that participants need to meet regarding dispute resolution when they join the network, for example, having clear policies for dispute resolution defined and shared through the network. So if anything happens, the user can resort to that mechanism and deal with the directly the participant involved. 

2. Decentralized and Open Network

We saw alignment among participants on what decentralized and open could mean in the context of a Regi-TRUST enabled network of networks:

• Metadata layover over existing trust networks: Regi-TRUST is designed to provide a metadata layer over all of the existing and potential future trust networks (likely in a certain defined domain). Anyone should be able to add a trust network to the Regi-TRUST enabled network but the metadata should be correct. There will eventually be a huge number of trust networks / trust lists, the value of Regi-TRUST is providing an infrastructure that enables a network of networks to be established with a set of procedures and governance that ensures the quality of the entries. 
• What could be centralized? There should be a transparent and collective decision making process/body, rather than a central authority made up of one or very few entities, that determines the policies and rules around metadata and participation. However, a centralized or centrally governed list of participants could exist for subscription by participants who don’t want to build their own or want to build further on. This doesn’t conflict with the overall openness of the network
• Desired outcome and operational considerations: We have to have something that is going to be accurate, stable, and trustworthy whilst being as open as possible. However, since this is a new model, anyone implementing Regi-TRUST for a network of networks may not be able to start at a massive scale to include everyone they want. 

3. Vetting and Presentation of Participants' Metadata

• Metadata on technical standards vs. how technology is operated: There are two different things - one could trust the technology but not trust the SOPs around how the technology is being used to issue credentials.
• Trustmarked participants: There could be a committee that is auditing information provided by a prospective participant. The validated participants can have a green checkmark which suggests that they pass the initial verification to join. Those who didn’t pass the validation can also be allowed join the network (without the green checkmark), and users can decide for themselves whether they are going to trust the unvalidated ones or not.
• Leverage existing network of governments/nation states: ICAO is operating a system that is nation states oriented - issuers are all nation states. 
  • ICAO utilizes the state context they have. UNDP has the possibility of leveraging the UN or UNDP network, the state representatives/contacts to support the validation in the same way.
  • When it gets to the private sector, ICAO still asks the state counterparts that they have from the country where a company is from to provide information to the extent possible. 
  • Make sure that a participant is not reputationally damaging - check against procurement lists and sanction lists of the UN, making sure any particular entity hasn’t been involved with the UN in a suspected manner.
  • Not everything can be validated, so it is important to be transparent in the rules about what is or not being done. 

For our team's initial input to the questions and full notes of the discussion, please see here.