Re: KR schema for covid

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:

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