KR schema for covid

Adrian
thanks for this info- I am sharing with AI KR CG IN CC-  thinking this may
serve as the basis for a
public 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 elaboration
Thanks,
best
P

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