Versions Compared

Key

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

...

TimeItemWho
2 minWelcome & Antitrust Policy NoticeChair
10 minIntroductionsChair & PM
5 minBackgrounderChair
XY min

Good Health Pass Blueprint Review

TBC

XY min WHO Registry GuidanceTBC
5 min

Tooling

Chair
3 minWrap upChair 

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

Meeting Notes

  1. [Darrell] Start with present the diagram
    1. Introductions 
      1. Sergio from LACChain and we are working with Marcos
      1. Introductions 
      2. I think we're starting to get to the point of what are the real problems that we need to solve.
      3. In the initial phases, at least have good health pass, short term long term is really not our problem, the problem shouldn be solving the trust registry side.
      4. The concept here is Julian is not able to make it today, but Julian is fulfilling a role in the UK, and other countries where, in essence, his company helps you get access to your data from your own health system, it does some local processing knows, for example in the UK, that this particular vaccine.
      5. there's nothing precluding trust here, as you were in a world where if iI can get a verification form and verify myself or I can choose to trust the digime to do it for me
      6. Digi.me model makes the TR simple. 
    2. [Stephan] We want to be care with recommend a model that prompts a monopoly 
      1. This could cause liability. I just want to be a little more careful. I think then that it's a toss-up. Agencies have one that's true in a particular situation where a verify  trusts an APP.
      2. I'm I think what we need to we should have enough foresight to make sure that this is not,  falling into their own rapidly building.
      3. Stephan Baur: And, and so I think there is a situation where somebody can actually verify that you still have transparency to the entire validation chain or trust chain. That a vendor to trust-anchor that started, this would provide will be of immense value.
      4. The delegation to such an APP is not the issue. It's only saying check that other necessarily registry, or trust framework is the authority, users have to be cognizant about the borders.
    3. [Drummond] outputs, meaning a credential or pass that we're talking about that's what you're saying right there oh yeah yeah.
    4. [Darrell] yeah you know if I received from the government of Ontario that I got a credential. But downstream if digi me was able to turn that into something that a verify would say yeah Darrell is vaccinated.
      1. [Darrell] this might be something that we start with for the 30 days. . .
      2. Some groups might want the simplified where someone assume responsibility
      3. Keep in mind “what does good look like”
      4. A lot of people will likely be doing stuff that's really not good enough, but we don't even have a norm to look at.
      5. We teach the world what good looks like so that we can't have that oh I just did this buddy over here has an APP and I just use it for the rest of time.
    5. [Darrell] How do we handle counties that are 100% PKS WHO and others that are 100% DID based
      1. How do we handle a ecosystem with both Centralized PKI and Decentralized PKI
      2. Marcos will also share diagrams
    6. [Drummond]
      1. Couple diagrams that outlines the trust architecture
      2. <diagram>
    7. Starting points - roots of trust
    8. We specify the requirements for each ecosystem to assign a DID 
      1. This helps us resolve both x509 and DID based registries
      2. Any authority that wants to be a root of trust MUST comply with this model
      3. This is wrps the x509 with a DID / DID-document
      4. Standardize a protocol
      5. We don’t know if WHO is going to be publicly verifiable. They likely won’t assign a DID to their root servers. There might need to be somebody that acts as a proxy to resolve DIDs to x509.
    9. [Todd] We should present this plan at IIW and get others considering the DID-x509 resolution 
    10. [Drummond] <verification protocol assumptions slide>
    11. Stephan] should that not be a chain of VCs rather than DIDs? Or at least reference DID docs
      1. This breaks a whole model in my mind
      2. I wonder how difficult it would be to change x509 to use a DID
    12. [Darrell] @Stephan - I’ve debated this a lot and there are pros/cons both ways. One is walking up 5 levels through VerCreds to finally get to a DID and needing to look them up anyway.
    13. [Drummond] I have a couple quick slides to discuss 
      1. They have a DID they publish the DID document wherever they choose, or in multiple places right, this is how they can say this is really you know the ID for our service and that document will expose again i'm just saying.
      2. Either there's two types of endpoints for resolution. Resolution DIDs, that simple, or key based, and they can support one or both. And then the other assumption this protocol is that a good health pass compliant vc or verify.
      3. verifiable credential and verifiable presentation, the distinction is getting more and more important what is going to be verifying is usually a presentation.
      4. This includes three things the DID for the EGF, and the credential type, so they know how to start resolution the DID for the or X 

    ...

    1. [Drummond] Of the verified clincher or present type presentation type and that's so that the verify or can only verify the issuer is.
      1. The type is needed to be sure that the issuer is authorized for that kind of credentials, so you don't have a testing lab issuing a vaccination certificate, or vice versa, or anything else, so those are the starting points at which point the protocol.
      2. The trust registries are either going to say, in the case of DID, register is basically saying yep registered and valid for that type
      3. In which case the final step is to resolve the DID to the document to get the key you need to do verification.
    2. [Marcos] Presenting LACChain diagrams
    3. <insert ppp>
    4. [Marcos] I work in the American Development Bank, the Inter American Development Bank is like the World Bank.
      1.  Innovation of these countries is coming from the IDP so basically my conversations are with a specialist of my institution That are managing loans and with the counterparts from the region that are deciding which projects, they want to do
    5. [Marcos] In the topic is around vaccination credentials, the problem is that there is no clear solution. What we are doing is different than the proposal Drummond showed.
      1.  Drummond was describing the problem that I'm facing; in order for people to understand what that is the solution, I needed them to understand the problem we are trying to solve.
    6. The problem that we are facing 
    7. We need a flexible way to connect all entities to 
      1. We are introducing technology
      2. What is the 
      3. What are the identifiers
      4. What are teh trust frameworks thet we need to make all this possible
      1. We need a flexible way to connect all entities to 
      2. With regard to the certs centralized vs decentralized both have pros and cons
      3. Decentralized is better because it enables the owner of DID to rotate keys. This is difficult in the centralized model because id is slow andburrden with process

    ...

    ...

    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 

    ...


           

    Action Items

    1. TBC