Re: KR schema for covid

Adrian
thanks-

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