Week 3: Process (2)

Hi all,

Last week, we zeroed in on some key processes on the users/verifiers’ end: 

Levels of user access: The Regi-TRUST enabled 'network of networks' can give network participants the technical capability to limit user access to their sensitive data, such as certificate revocation list, based on types of users. The key question is what should be within the scope of meta network governance and what is not. There is no clear conclusion for this but a suggestion was proposed as follow: 

• The meta network is responsible for getting and validating all initial required information (including endpoints) from network participants and guaranteeing secure access to it. 
• The meta network is not responsible for defining the access protocols to the information and leaves that for network participants themselves so each participant can define for themselves who can access what data. 

Onboarding of users/verifiers: Categorization of users and whether there should be vetting (and what type of vetting).

• Given the consideration of letting network participants manage user/verifier access to their (sensitive) data, the question of user categorization and vetting came into the picture. 
• User vetting: it is expected that most, if not all, network participants will be network users as well. Therefore, we can assume that this type of users will go through proper vetting. It is a matter of defining, onboarding and vetting of users who are not network participants at the same time. 

Detailed view of verification services:

• Users can operate backend services for verifications that use Regi-TRUST for discovering trust services and building trusted lists.
• Regi-TRUST may not be implemented to be accessed by verifier apps directly (see graphic below); instead, users run backend services that download keys from their trusted sources and make them available for verifier apps to use.

• Users cache keys and data in the backend services: what should be the policies related to this?
• Draw a comparison between the Regi-TRUST model and the eIDAS model for better clarity. The Regi-TRUST adopts a more decentralized model.

Other key points raised: 

• Revocation of network participants: Policies for this need to be defined in the governance of a Regi-TRUST enabled ‘network of networks” 
• Define minimum requirements for the ‘network of networks’: Two levels of discussions have been taking place - 1) which areas we need to define minimum requirements / quality level  for (e.g. revocation of network participants, eligibility of participants, applicable levels of assurance) and 2) what should be the minimum requirements for each identified area. 

'Homework' before the last week discussion:

• What do you think should be the minimum requirements for a global trust network for COVID-19/immunization certificates? You can consider adopting a risk-driven approach - what could go wrong so we need minimum requirements in place to avoid that. 
• What are the incentives for existing and new networks of COVID-19/immunization certificates to join a meta network?

Any thoughts before the last live session, please feel free to share directly in the last week's asynchronous forum! 

 A few thoughts to the final questions:

1. As minimum requirements, I would suggest that proper on-boarding of network participants is important. Users like ICAO would be reticent to join any network where participation could endanger reputation through being associated with a network that is prone to illicit entry by fraudulent participants etc. I think a mechanism to publish and make clear a network's own policies is important too...everyone involved should not necessarily have the same policies and rules, yet it should be clear to the downloading user how they might differ so that that user can make informed decisions. 

2. Our focus in ICAO is on usage at borders and in travel. In this regard, participation in any network that helps stakeholders validate health certificates in travel in a seamless and trusted manner is valuable, as long as this doesn't diminish the trust in its own credentials and network and introduce vulnerabilities or risks by itself. If the global border management community is looking towards the use of the meta network, we would be sure to be part of it.