Re: KR schema for covid

Dear all,
I recommend we define a set of COVID-19 related issues.
I have submitted off list to Owen Ambur some of the projects and programs I am personally working on.
Because most of the COVID-19 issues of interest to us are process, event and trigger driven, I recommend we look at how we can extend the VC concept to a wider range of important subjects, for example quarantining/isolating, tracing and tracking, COVID-19 certification for travel and hospitality operations.
Basically anything that requires certifying a person, company, location or activity, or product or service provided safe.
The travel and hospitality industry are in dire need of such.
For practical purposes we may also want to help making sense of the enormous amounts of articles being produced on all manner of issues related to COVID-19, not only is it important to classify the huge body of documents, but for numerous reasons I can think of VC can also be used to classify documents deemed vital to ICU protocols evaluation, possible new drugs, alternative treatments and (performance) evaluation of social distancing, curfew and shelter in place policies adopted.

Milton Ponson
GSM: +297 747 8280
PO Box 1154, Oranjestad
Aruba, Dutch Caribbean
Project Paradigm: Bringing the ICT tools for sustainable development to all stakeholders worldwide through collaborative research on applied mathematics, advanced modeling, software and standards development 

    On Sunday, April 26, 2020, 12:26:55 AM ADT, Paola Di Maio <paoladimaio10@gmail.com> wrote:  
 
 Adrianthanks-
in the post you share valuable knowledge (I am not thinking of the rest of  the arguments and their meaning/impact/implications)
If you  or others think at some point the information you shared can be valuable and used by  others in terms of helping to conceptualize covid related facts we can make a knowledge schema out of it and publish it.  Even only a draft version should not take too much additional work-
I am working on other things at the moment with pressing deadlines, I ll put this on my to do list - if someone gets to this earlier, the better
PDM
On Sun, Apr 26, 2020 at 11:11 AM Adrian Gropper <agropper@healthurl.com> wrote:

Paola,
I am not a KR expert. My goal in posting this adoption sequence is to stimulate a discussion around product-market fit for SSI and the standards we work on. 
The sequence would look the same for a prescription or a SCUBA diver certification or an inspection sticker for your car. The shared pattern is an expert issuing a credential on their own authority rather than the authority of an institution that might be their employer. Decentralization could mean more money in their pocket. 
Use cases like a diploma or a bank loan are somewhat different because the authority to issue a credential to a student or a borrower rests with the institution and the individual that happens to sign the diploma or the check is merely an agent of their employer. In this case there is still room for decentralization but not as much as in the case I detailed.
I’m making a point about product-market fit for SSI. Decentralization is powerful medicine and some actors will see it as more of a benefit than others. 
- Adrian
On Sat, Apr 25, 2020 at 8:10 PM Paola Di Maio <paola.dimaio@gmail.com> wrote:

Adrianthanks for this info- I am sharing with AI KR CG IN CC-  thinking this may serve as the basis for apublic KR schema for Covid, 
Could publishing a vocabulary, or an entity relationship catalog be useful to facilitate the interop you mention , in which case we couLd start a draft based on the info you post below and circulate to interested parties for comments and elaborationThanks, bestP

---------- Forwarded message ---------
From: Adrian Gropper <agropper@healthurl.com>
Date: Sat, Apr 25, 2020 at 11:41 PM
Subject: Decentralized Adoption of Decentralization
To: W3C Credentials Community Group <public-credentials@w3.org>


cross-posted to https://difdn.slack.com/archives/C4X1Z0T7H/p1587828480246600

I’m using the immunity credential use case to sequence adoption into 8 steps (table below). I hope to have a session at IIW about this sequence of standards. It might also inform DIF, SDS, and glossary discussions.


I strongly recommend reading the Solid / Sovrin paper “COVID-19 Antibody Test Certification There’s an app for that” https://arxiv.org/abs/2004.07376 to understand the reason for my approach. HT Kaliya for pointing it out.


The sequence below is captured in our Trustee Immunity Passport demo which I hope Solid, Sovrin, and others will sponsor and interop with. See: https://bit.ly/Trustee-Summary 

Editable gdoc is here: https://docs.google.com/document/d/1KX6Xcm_jAzj_CWMhoYjFBOX7KXE8vVEgYHua6Kj_AKo/

| 
Step
 | 
Standard component introduced
 | 
Why is this the next step to decentralization 
 |
| 
1
 | 
Doctor gets a secure element - DID
 | 
Enables a non-repudiable signature.
 |
| 
2
 | 
Patient gets an authorization server - UMA AS
 | 
Otherwise report remains centralized to the doctor’s employer institution, a hospital. 
 |
| 
3
 | 
Hospital can present human-readable report with photo - SSL
 | 
Patient can direct the destination verifier. Biometric mitigates impersonation. 
 |
| 
4a
 | 
Verifier installs secure display app - JWT
 | 
Necessary to trust patient as holder
 |
| 
4b
 | 
Hospital can present a signed human-readable report - JWT
 | 
Allows patient to direct destination to personal data store (PDS). Report includes photo or drivers’ license number
 |
| 
5a
 | 
Hospital installs identity provider API - OpenID Connect
 | 
Allows doctor to sign-in and sign a credential directly in the patient’s PDS with their DID
 |
| 
5b
 | 
Verifier installs signature verification to doctor directory or DID
 | 
Verifier will need the doctor’s public key from somewhere.
 |
| 
5c
 | 
Patient PDS installs doctor sign-in and report signature API
 | 
Allows patient to avoid tracking of credential use by the hospital 
 |
| 
6a
 | 
Patient PDS installs doctor credential verification - VC
 | 
Allows doctor to sign-in and act independently of the hospital
 |
| 
6b
 | 
Doctor installs credentials storage. - VC
 | 
Allows doctor to avoid tracking of credential use
 |
| 
6c
 | 
Hospital or licensing board installs credentialing API - VC
 | 
Allows doctor to avoid tracking of credential use
 |
| 
7
 | 
Verifier installs doctor’s credential verification - VC
 | 
Allows doctor to avoid tracking of credential use by the hospital operating a directory - revocation method is involved
 |
| 
8
 | 
Immunity credential is standardized as a VC
 | 
Allows machine verification of the patient’s credential as long as the biometric can also be checked by the machine. 
 |
| 
 | 
Decentralization is achieved...
 | 
for the immunity credential use case. Note that the patient may not need a DID.
 |


Hope this helps,- Adrian