W3C home > Mailing lists > Public > public-credentials@w3.org > April 2020

Re: [toolsCCI] Hypothetical COVID-19 Credential VC Data Model v2

From: Margo johnson <margo@transmute.industries>
Date: Tue, 21 Apr 2020 11:06:21 -0500
Message-ID: <CAHunGkiCyNd3YbQwArFRK_CmWsJb3B2TTZ8T=sOVkJ7fkC0yjA@mail.gmail.com>
To: Ser-huang Poon <ser-huang.poon@manchester.ac.uk>
Cc: "main@toolscci.groups.io" <main@toolscci.groups.io>, Bla?? Podgorelec <blaz.podgorelec@gmail.com>, "toolsCCI@groups.io" <toolsCCI@groups.io>, "W3C Credentials CG (Public List)" <public-credentials@w3.org>
Plus one for the utility of compatibility with X.509, as enabled by the
proposed well-known DID configuration.  It also provides a helpful bridge
towards supporting the range of European digital signature options.

Example of how e-signing company Docusign describes use of X.509 standard:

[image: Docusign eIDAS Signature Standards.png]
Source:
https://www.docusign.com/sites/default/files/Standards-Based-Signatures-Data-Sheet.pdf


ᐧ

On Mon, Apr 20, 2020 at 5:26 PM Ser-huang Poon <
ser-huang.poon@manchester.ac.uk> wrote:

> I think if the credential comes from the same issuer, the system should
> include ability to revoke. Harder if the holder shops around for better
> credentials.
>
> On 20 Apr 2020, at 19:21, orie <orie@transmute.industries> wrote:
>
> 
> Replying with permission to the lists... excellent questions:
>
> On Mon, Apr 20, 2020 at 11:43 AM Blaž Podgorelec <
> blaz.podgorelec@gmail.com> wrote:
>
>> Dear Orie,
>>
>>
>> I am examining your work at "COVID-19 VC (VCC)", and while I am studying
>> the material, I have one non-technical (or maybe it is?) question/concern.
>>
>>
>> Let's consider "travel" use-case when I want to go abroad. In this case,
>> the customs officer wants (needs?) to check/validate that my CVV result is
>> NEGATIVE.
>>
>>
>>
>>    1. For example, I was tested yesterday, when the result was negative,
>>    and I have been tested today when the result was positive.
>>    2. Now I am approaching the border, where customs officer
>>    check/validate the VCC, which I provide to him.
>>
>>
>>  At this point, the question/concern arises... How a custom officer can
>> validate that I am not cheating him - that I actually provided to him
>> really LATEST VCC. The example of cheating can be if I do not provide to
>> him the LASTEST test (which in this example is positive), and I provide him
>> the test from yesterday, which was negative...
>>
>> Is there any research, solution, how such cases can be prevented?
>>
>
> In systems like OAuth OIDC, it's possible to revoke existing bearer tokens
> when a new one is issued, because there is a single centralized issuer, and
> they control the subject identifiers "iss" and "sub".
>
> In decentralized systems there are multiple issuers, and the situation is
> actually even worse than you describe... I might get a negative test from
> vendor A, and then keep getting retested at other vendors until I can hit
> the false positive rate for the test and get a positive test.... how will
> the vendors know that this is the 3rd time I was tested in the last week?
>
> Typically we call these kinds of attacks a
> https://en.wikipedia.org/wiki/Sybil_attack ... and they are pretty common
> in any free to join / decentralized system.
>
> Solutions range from requiring biometric in person checks (preventing the
> attacker from generating more than 1 unique id, or some other form of
> relying on a strong central issuer)... When the subject can control their
> identifier, and the issuer has no way of knowing if this person has ever
> been tested before... the problem will persist.
>
> It's a great question, I'm sorry I don't have a better answer for it other
> than defaulting to some centralized registry... it's a hard problem... and
> there are lots of papers on the topic:
>
>
> https://scholar.google.com/scholar?hl=en&as_sdt=0%2C44&q=sybil+attack+detection&btnG=&oq=sybil
>
>
> OS
>
>
>> Best regards
>>
>> Blaž
>>
>>
>>
>> V V sob., 18. apr. 2020 ob 21:42 je oseba Orie Steele
>> <orie@transmute.industries> napisala:
>>
>>> Thanks for the feedback regarding the v1 example covid credentials.
>>>
>>> Here is a v2 that was made possible thanks to your feedback:
>>>
>>> https://w3c-ccg.github.io/vc-examples/covid-19/v2/v2
>>>
>>> Key features:
>>>
>>> - JWT and Linked Data Formats based on
>>> https://www.w3.org/TR/vc-data-model/#proof-formats
>>> - Split Test Credential from Travel Pass (Helps avoid mixing medical and
>>> travel information)
>>> - Based on an FDA EUA for Rapid Test developed by Cellex (I'm not
>>> affiliated, but I found their documentation helpful).
>>> - No required binding to existing identifiers such as Drivers License
>>> Number.
>>> - No required PII (optional image for cases where no
>>> credentialSubject.id link to an existing ID can be made)
>>>
>>> If you have questions, I prefer to answer on github issues:
>>> https://github.com/w3c-ccg/vc-examples/issues, but email also works.
>>>
>>> Regards,
>>>
>>> OS
>>>
>>> --
>>> *ORIE STEELE*
>>> Chief Technical Officer
>>> www.transmute.industries
>>>
>>> <https://www.transmute.industries>
>>>
>>
>
> --
> *ORIE STEELE*
> Chief Technical Officer
> www.transmute.industries
>
> <https://www.transmute.industries>
> _._,_._,_
> ------------------------------
> Groups.io Links:
>
> You receive all messages sent to this group.
>
> View/Reply Online (#142) <https://toolsCCI.groups.io/g/main/message/142>
> | Reply To Group
> <main@toolsCCI.groups.io?subject=Re:%20Re%3A%20%5BtoolsCCI%5D%20Hypothetical%20COVID-19%20Credential%20VC%20Data%20Model%20v2>
> | Reply To Sender
> <orie@transmute.industries?subject=Private:%20Re:%20Re%3A%20%5BtoolsCCI%5D%20Hypothetical%20COVID-19%20Credential%20VC%20Data%20Model%20v2>
> | Mute This Topic <https://groups.io/mt/73114730/4508317> | New Topic
> <https://toolsCCI.groups.io/g/main/post>
>
> Your Subscription <https://toolsCCI.groups.io/g/main/editsub/4508317> | Contact
> Group Owner <main+owner@toolsCCI.groups.io> | Unsubscribe
> <https://toolsCCI.groups.io/g/main/leave/8108736/11039175/xyzzy> [
> ser-huang.poon@manchester.ac.uk]
> _._,_._,_
>
>

-- 

*MARGO JOHNSON*

Head of Product

LinkedIn <https://www.linkedin.com/in/margojohnson/>

Medium <https://medium.com/@margo.e.johnson>

www.transmute.industries


<https://www.transmute.industries/>

Docusign_eIDAS_Signature_Standards.png
(image/png attachment: Docusign_eIDAS_Signature_Standards.png)

Received on Tuesday, 21 April 2020 16:13:21 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 24 March 2022 20:24:58 UTC