Page History

<DAY> March <#>

Time	Item	Who
2 min	Welcome & Antitrust Policy Notice	Chair
10 min	Introductions	Chair & PM
5 min	Backgrounder	Chair
XY min	Good Health Pass Blueprint Review	TBC
XY min	WHO Registry Guidance	TBC
5 min	Tooling	Chair
3 min	Wrap up	Chair

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

[Darrell] Start with present the diagram
Sergio from LACChain and we are working with Marcos

Introductions
I think we're starting to get to the point of what are the real problems that we need to solve.
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.
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.
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
Digi.me model makes the TR simple.

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.
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.
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.
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.

[Drummond] outputs, meaning a credential or pass that we're talking about that's what you're saying right there oh yeah yeah.
[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.

[Darrell] this might be something that we start with for the 30 days. . .
Some groups might want the simplified where someone assume responsibility
Keep in mind “what does good look like”
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.
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.

[Darrell] How do we handle counties that are 100% PKS WHO and others that are 100% DID based

This helps us resolve both x509 and DID based registries
Any authority that wants to be a root of trust MUST comply with this model
This is wrps the x509 with a DID / DID-document
Standardize a protocol
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.

[Todd] We should present this plan at IIW and get others considering the DID-x509 resolution
[Drummond] <verification protocol assumptions slide>
Stephan] should that not be a chain of VCs rather than DIDs? Or at least reference DID docs

[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.
[Drummond] I have a couple quick slides to discuss

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.
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.
verifiable credential and verifiable presentation, the distinction is getting more and more important what is going to be verifying is usually a presentation.
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

...

[Stephen] We need to talk about the what then moving into solutions of the how.

Agreed - this is just one possible solution
This gives hope that there are multiple approaches to solving. What is the min than needs to be in a TR?
How do we get it to work both ways x509 and DID
Comparing the identifiers DID in one and the public key in the other
True if we are talking about self-signed x509 certs

[Sergio] So basically the process of education is being presented in a general way, so information is structured and verified by of cryptographic.and we ensure the issuer is authorized issue this type of credential
[Marcos] Then authorized by the Ministry of Health right, so we create that root of trust through the ids, so it is not necessary to use verifiable potential for these root of trust, and this was a conversation that was going on the chart because, if we have a smart contract.

The DID register it's not exactly a smart contract, we use other things like events in order to register, in order to have the idea of what are the kinds of smart contracts for different purposes.

[Stephan] Is it, is it possible to find it out on Friday next week to sort of synthesize from yeah that trouble you as well,

...

Space shortcuts