2021-03-30 Trust Registries Drafting Group Meeting Notes

Tuesday March 30

Attendees

• Co-Leads: Darrell O'Donnell
  
• ID2020 PM: Todd Gehrke 

Participants: 

• Marie Massery (IATA), 
• Marcos Allende Lopez (LACChain/IADB), 
• Patrice Van de Velde (UNBLOCKED), 
• Stephan Baur (Kaiser Permanente), 
• RJ Reiser (Liquid Avatar Tech)
• Sid Mishra
• Viola ICTS
• Steve Megennis
• Marcos Loiez
• Sankarshan 
• Drummond Reed

Agenda Items

Meeting Notes

1. Preparation for the meeting
   1. [Darrell] key thing to drive is to find how and where trust registries fit in (see Challenge #6); alignment vs agreement as way to make progress (‘convergence over consensus’) See link (the content was created by Drummond Reed as the primary lead among others including Todd, Rebecca)
   2. Darrell has been working on trust registries and has helped implement one. Key concepts and topics around trust registry
   1. Who is the issuer
   2. Who is the holder
   3. Who says that it is actually the issuer
   3. ‘Zone 3’ actions/events/flows - when the credential is being presented - what are the questions which can be addressed by the trust registry
   1. How does the world know that someone complying with GHP solution presents a credential and they can trust what is behind the credential
   4. [Todd] during the drafting of the challenge trust registry happened to be discussed as a solution (rather than other instances where there are actual challenges described). There are existing implementations of the ‘root of trust’ model and we need to figure out how to be inclusive
   1. [Steve Magennis] What does that mean?
   2. [Todd] 
1. Blueprint from the GHP

1. [Marcos] It will be useful to try to think how entities are going to implement the concept of trust registry and which kind of trust registry - Including centralized registries owned by the ministry of health. centralized or decentralized? Whether there will be APIs available to be consumed by others. The different types of registries bring about different topics around governance, data protection and usage. Public lists of (authorized) issuers of verifiable credentials - interaction/interoperability and data exchange would need to have these data lists to be exposed via APIs (?) It is not defined by the W3C standard what needs to be verified in a verifiable presentation. For example, at a minimum it is required to verify among the various elements in the presentation viz the validity, the issuers and that the holder matches etc and other things. See more
2. [Darrell] WHO Global Federation - PKI - builds on an existing model which adopts the ‘root of trust’. To make ‘bilateral exchanges possible’ how do we remain assured that the correct datasets are being exchanged using the appropriate authority. See recording (around 35th minute) for how the WHO Guidelines overlap with the Blueprint document
1. MemberPass example of a simple trust registry - as a list which handles national/state to address whether an entity is definitively a credit union
2. How do we handle a new situation that can be flexibly fit into the proposal we are creating? Federated DID registry might fit in nicely to address this
3. DID WoT model exists too
3. [Drummond] Conventional and hierarchical approaches to this are a concern. If this particular group can come up with a design that is a superset of the WHO approach (for issuers of strictly vaccination credentials) which authorizes member countries (only) who in turn have their own list of authorized verifiers. The current state of the PKD hierarchy can be downloaded and used offline.
1. Conversations with IATA and ICAO on the topic of airlines requesting access to the ePassport PKD - IATA requires this to be open verification. Management of centralized PKD infrastructure is not feasible and thus a DID based infrastructure is preferred

 [Additional context notes from Marcos]

What form can practical trusted registries take?

-    Centralized

-    Decentralized (Permissioned, Permissionless, Federated)

-    Other?

Which information is necessary to register in a trusted registry by an issuer when a verifiable credential is issued?

-    Hash of the content

-    Status of the credential

-    Link to the issuer (DID + digital signature)

-    Link to the subject

Which information is necessary to verify against a trusted registry when they are presented to verifiers? 

-    The issuer as an authorized entity

-    The status of the credential

-    The content/claims of the credential

Who is responsible for defining or maintaining lists of entities authorized to be issuers of specific verifiable credentials in specific contexts or jurisdictions (i.e., the laboratories authorized to issue certificates of COVID-19 tests in Honduras)

How do we specify in the verifiable credential the trusted registry where the proofs are registered?

How do we establish a standard for both centralized and decentralized registries to store and make available the proofs in a way that is common to everyone, so once the verifier figures out the trusted ledger to be checked and the access point to it (which should be able to do directly from the credential), the protocol to accomplish verification is standardized

Presentations 

• Initial Presentation (Google Slides)

Key Resources:

• GHPC Blueprint Outline v2 - The Trust Registries section is detailed on pages 25-26.
• WHO SVC Guidance

Recording - Link

Notes

1. Welcome and Linux Foundation antitrust policy - http://www.linuxfoundation.org/antitrust-policy

2. Topic A

3. Topic B  

4. Topic C 

5. Wrap up 

• Next steps

Action Items

1. TBC