Versions Compared

Old Version 5

changes.mady.by.user Todd Gehrke

Saved on

compared with

New Version Current

changes.mady.by.user Todd Gehrke

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

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

...

  1. Preparation for the meeting
    2. Blueprint from the GHP
    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

...

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 

Key Resources:

Notes

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

...