Re: Hypothetical COVID-19 Credential VC Data Model v2

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>