1. Messages
  2. Hypothetical COVID-19 Credential VC Data Model v2

Re: Hypothetical COVID-19 Credential VC Data Model v2

orie <orie@...>
 

Replying with permission to the lists... excellent questions:

On Mon, Apr 20, 2020 at 11:43 AM Blaž Podgorelec <blaz.podgorelec@...> 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@...> 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




--
ORIE STEELE
Chief Technical Officer
www.transmute.industries
Join {main@toolsCCI.groups.io to automatically receive all group messages.