- From: Margo johnson <margo@transmute.industries>
- Date: Tue, 21 Apr 2020 11:06:21 -0500
- 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>
- Message-ID: <CAHunGkiCyNd3YbQwArFRK_CmWsJb3B2TTZ8T=sOVkJ7fkC0yjA@mail.gmail.com>
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/>
Attachments
- image/png attachment: Docusign_eIDAS_Signature_Standards.png
Received on Tuesday, 21 April 2020 16:13:21 UTC