Versions Compared

Key

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

Thursday April 1

Attendees

Participants: 
  • Marcos Allende Lopez (LACChain/IADB), 
  • Stephan Baur (Kaiser Permanente), 
  • RJ Reiser (Liquid Avatar Tech)
  • Sid Mishra
  • Steve Megennis
  • Marcos Loiez
  • Sankarshan Mukhopadhyay
  • Drummond Reed
  • Julian Ranger
  • Savita Farooqi
  • Scott Perry
  • Kaliya Young

Agenda Items

TimeItemWho
2 minWelcome & Antitrust Policy NoticeChair & PM
5 minIntroductionsChair & PM
5 minBackgrounderChair
+Open DiscussionGroup
2 minWrap upChair & PM


Meeting Notes

  1. [Darrell] Anti-trust and membership policy introduction
  2. [Todd] Work at this group and GHP was reflected in conversations at the WHO call of 31Mar
  3. Key interoperability questions - [Darrell] some opening remarks on the topic of trust registries as a solution and where they fit in (are they a solution or a challenge?)
    1. Is there a way to establish transitive trust between different parts of the GHP digital trust ecosystem
      1. [Todd] establishing a globally scalable, jurisdiction specific registry is a challenge eg. X.509 trust registries - how do we work with those?
      2. [Darrell] analogy of lanes/queues to describe the nub of the issue
      3. [Julian] ‘who is being registered in these registry’ - assumption is people making the tests and vaccines (this massive trust registry is impossible) a short term solution is that the people who provide the trust (the app providers) provide it directly when presenting credentials.

...

  1. [Drummond] If we agree about: 1) multiple roots of trust, 2) each root of trust has a governance framework, then 3) is that we need a common protocol for an issuer to locate and query a trust registry using metadata from the governance framework.
  2. [Todd] ‘verifying the holder’ is a part of the Identity Binding WG; contents of the credential is also out of scope for this WG. Agreement on the discrete questions would help make progress - we are still talking ‘big picture’ in the discussions. It is time to focus on the questions we are trying to solve.
    1. [Scott] Todd raises a challenge in the fact that every individual working group wants to solve all problems.  It is up to Todd and leaders to keep us focused on our unique challenges to solve
  3. [Stephen Baur] Just a point from the issuer perspective: the # of registries becomes an issue when large and issuers need to “register” with each separately.
    1. suggest to formulate what “registering” means, like quality processes and audits of the issuer. One big concern: if the private keys are leaked trust vanishes quickly
  4. [Savita] using the framework of ‘necessary’ and ‘sufficient’ may be a way to find the direction and focus of the work output - ‘what is the verifier looking for’
    1. [Stephan] suggest to keep focus on registries of issuers and leave verifier to a separate concern.
    2. [Drummond] Marcos proposed that verifiers need 3 standard items: 1) is the issuer authorized, 2) what is the issuer’s public key for verifying the credential, 3) how do I check if the credential is revoked.
  5. [Drummond] Proposal: delegate the question of whether a governance framework supports “verifying the verifier” to the governance authorities for the governance frameworks.
  6. [Drummond responding to Julian] there exist interdependencies between different drafting groups. There’s a meeting of Credential formats and exchange protocols coming up and so there is yet no clear answer is it ‘just W3C VCs etc’
  1. [Steve Magennis] see below
  2. [Drummond] Creating a document to have key/specific questions up for answering. Each member goes in to provide detail/links/thoughts to the approaches to the questions. To get a collective view of the key questions and preliminary thought about the answers.
    1. [Todd] document of key questions https://docs.google.com/document/d/1mVZ5pRGBhb7VK5pSPsaZwaDo9hRjlZiQmCdggknP4ec/edit#heading=h.bqnrtc8kz7hb 
  3. [Kaliya] - what are the other systems doing - the “closed loop” (Wave1)

...

  1.       MUST have a means of recognizing the issuer or certifying authority that is bound to the claim or credential presented (e.g. CDC issued credential or CDC authorized credential)
  2.       MUST have a means of verifying that the issuer or certifying authority is who the verifier thinks it is (e.g. Centers for Disease Control and Prevention NOT Coronavirus Disease Consortium)
  3.       If the verifier intends to rely on a certifying authority rather than the issuer directly the verifier SHOULD also have a means of verifying that acceptable certification is active and properly bestowed upon the issuer - for the given context and intended purpose.
  4.       MUST have a means of comparing the issuer or certifying authority to a predetermined list (internal list)
  5.       MUST have confidence the claims or credentials are sufficiently current at the time of presentation
  6.       MUST have confidence the claims or credentials presented have not been altered since they were issued 
  7.   MUST have the ability to verify holder and principle of the credential is the same

Presentations 

...


Notes

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

...