- From: Adrian Gropper <agropper@healthurl.com>
- Date: Fri, 10 Apr 2020 22:06:35 -0400
- To: Orie Steele <orie@transmute.industries>
- Cc: main@toolscci.groups.io, toolsCCI@groups.io, "W3C Credentials CG (Public List)" <public-credentials@w3.org>
- Message-ID: <CANYRo8iKu15-mYyXrQXpYgeHffftWGi8+3vPJksaC4+jHP_7Sg@mail.gmail.com>
Apologies if I missed the answer elsewhere but I'm lost when it comes to the photo on a driver's license. I'll ask again: - The state driver's license in my pocket has a photo, a license number, and some tamper-resistant features. - When I go get a serology test, the person drawing my blood might look at my license, write a hash of my license number and photo on the tube and send to the lab - I log in to the lab, search for the hash that was put on the tube and download the result to my wallet - When someone asks for my result, I show them my driver's license with my photo and the hash of the number matches the VC I received from the lab So, - My photo and the driver's license number never left my wallet. - A tamper-resistant scheme has to prevent me from changing the photo on my license without also changing the hash that labels the sample and the result. What am I missing? - Adrian On Fri, Apr 10, 2020 at 11:56 AM Orie Steele <orie@transmute.industries> wrote: > CC'ing the W3C Mailing list, since this discussion of COVID-19 Credentials > has been discussed there as well... > > Most of the attributes are just leftovers from basing the credential on a > Permanent Resident Card. > > I'm not sure how the VC Data Model values would be collected, but it's > sometimes the case that an organization will use birthdate, gender and name > to double check that things like SSN / Driver's License are accurate (I've > seen this kind of overcollection in healthcare, for this exact reason)... > people make mistakes when entering data, having a group of values to check > against, helps mitigate the damage caused by these mistakes, but it's not a > perfect solution. > > I was expecting some request for a binding to a SSN / Drivers License... > I'm not sure that's actually a good idea, but I'm not an expert. > > My thought was that this credential could be provided by a laptop computer > in a tent, to people who have no existing identification (persons > experiencing homelessness, refugees, etc...) > > Obviously you don't need a picture or any of the PII fields if you are > just going to bind to another identity system like drivers license > number... but that credential won't work for people who are not > registered... > > The credential format could be expanded to include either a binding to a > well known identity system, OR the current approach... that might give us > the best of both worlds. > > If you can leave comments on the PR, that will help make sure that other > communities (outside of these mailing lists) can see your thoughts. > > Thanks for the feedback! > > OS > > > > On Fri, Apr 10, 2020 at 9:11 AM Daniel Hardman <daniel.hardman@evernym.com> > wrote: > >> Regarding Eric's comments about identifying the subject: >> >> The strategy proposed in the schemas doc in a couple places [1 >> <https://docs.google.com/document/d/1F5TLvAqCxj1kaPuPe6JhdECixwpbhKpEAb8eeQuDGT4/edit?disco=AAAAGVNlqxU>, >> 2 >> <https://docs.google.com/document/d/1F5TLvAqCxj1kaPuPe6JhdECixwpbhKpEAb8eeQuDGT4/edit#heading=h.31e94ad08nhb>] >> is to provide just enough information about the holder to let them be >> linked to other credentials (physical or digital/VC) that provide strong >> identification as needed. Orie's example is mostly aligned with this >> proposal, though its birthdate + photo may be a little more than is needed. >> The reasoning behind this is that a lab isn't going to be authoritative >> about facts of birth, and probably isn't going to take a photo of each test >> subject, but probably will check a stronger form of ID when the test sample >> is submitted -- so whatever form of ID they check, they need to embed just >> enough info about the holder in their results to allow the holder to >> present the same strong identification later. >> >> An example of how this could be tweaked to embody the proposal a little >> better might be to remove the photo and birthdate fields, and to add the >> following two fields: >> >> presentedIDType: a picklist with strings such as "drivers license", >> "passport", "national ID card", etc >> presentedIDNumber: the number from whatever strong identification the >> test subject supplied when submitting the sample >> >> Now it becomes clear how Eric can explain the trust dynamics to a harried >> government official: "The testing regime has the same trust dynamics as our >> national ID card/passport/driver's licenses, because that form of ID has to >> be used to submit a sample, and the same ID has to be used when presenting >> the test results." >> >> On Fri, Apr 10, 2020 at 3:58 AM Eric Welton (Korsimoro) < >> eric@korsimoro.com> wrote: >> >>> Fantastic! Thanks! >>> >>> I have a two questions and am thinking about how I could >>> summarize/present this to a government minister and relate it to a paper >>> form version of the same. >>> >>> First question: what is a TestCard? and what role does that play? >>> >>> Second - and this is a question that is more "general" - i'm not >>> nitpicking this specific example, but wondering more about credential >>> design in general and how we want to deal with the issue of subject >>> identification: >>> >>> - in addition to IgG and IgM - the context explicitly out a name-pair, >>> birthday, and something to do with the subject's sexuality, and the Person >>> structure from schema.org is called out, where most of the fields in >>> the Person model are not particularly useful for identifying a Person but >>> more about "describing" a Person or Person-like thing. >>> >>> Taken together, the presented information doesn't let me easily point to >>> a Person in a way that is immediately useful to me - for my use cases, I >>> would imagine one of the two: >>> - a national id number or semantic model, with optional image (citizens) >>> - a passport semantic model, with optional image (foreigners) >>> >>> I don't see this as a deep problem, because I can always build up >>> context that matches the identification context relative to my expected use >>> context - e.g. I want a checkpoint guard to be able to see the IgM/IgG >>> information, an F2F presented plastic national id card or passport, and >>> make a policy enforcement decision. >>> >>> So the question is just more generic - drawing on this example as a >>> starting point and using it to explore guidance - how can we do this >>> systematically so that we don't have covid credentials that vary for every >>> issuance context based solely on the properties of "subject identification"? >>> >>> One option is to push that out of the credential entirely, and let that >>> come from the wallet or alternate documents provided during presentation - >>> linked only by cryptographic material. But that brings in a raft of >>> problems and would be a hard sell in a 30 second elevator pitch to a busy >>> and distracted government minister - especially one with a mental model of >>> a physical form with tons of lateral information on it. >>> >>> The other option is to try to "define the subject information" in the >>> credential over and over - like, family name, given name, birth date, >>> sexual idiosyncracies, DUNS number, brand, funder, honorificSuffix, >>> interactionStatistic, product offerings, performances, employer, or many of >>> the other Person attributes ;) >>> >>> Perhaps a strategy of figuring out how to pool information in loosely >>> coupled groups - e.g. only the Ig* values in one group, the person >>> identification in another - perhaps as a one-or-more-of-many selection - >>> there might be a pattern we can establish here that clearly isolates the >>> human-identification-variability from the relatively stable science-driven >>> covid-19 data. >>> >>> again - my concern is for explaining this to a non-technical politician >>> as soon as Monday - and we assume that person has an existing mental model, >>> one that looks like "all the other test result documentation" they've seen >>> - with a bunch of socially-specific subject identification information, >>> issuer identification information, document photocopies, and signatures, >>> stamps, and more signatures, and more stamps - in red, for extra >>> authentication and security. >>> >>> best, >>> >>> -e >>> >>> >>> >>> On Fri, Apr 10, 2020 at 1:06 AM orie <orie@transmute.industries> wrote: >>> >>>> https://github.com/w3c-ccg/vc-examples/pull/30 >>>> >>>> Based on the new schema.org definitions for COVID-19 testing >>>> facilities and the DHS SVIP hypothetical Permanent Resident Card. >>>> >>>> Issued from a did:web, Presented by a did:key. >>>> >>>> Comments welcome. >>>> >>>> -- >>>> *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 (#89) <https://toolsCCI.groups.io/g/main/message/89> | Reply >> To Group >> <main@toolsCCI.groups.io?subject=Re:%20Re%3A%20%5BtoolsCCI%5D%20Example%20Immunoglobulin%20Detection%20Test%20Credential> >> | Reply To Sender >> <daniel.hardman@evernym.com?subject=Private:%20Re:%20Re%3A%20%5BtoolsCCI%5D%20Example%20Immunoglobulin%20Detection%20Test%20Credential> >> | Mute This Topic <https://groups.io/mt/72913968/1388286> | New Topic >> <https://toolsCCI.groups.io/g/main/post> >> >> Your Subscription <https://toolsCCI.groups.io/g/main/editsub/1388286> | Contact >> Group Owner <main+owner@toolsCCI.groups.io> | Unsubscribe >> <https://toolsCCI.groups.io/g/main/leave/8108734/298559501/xyzzy> >> [orie@transmute.industries] >> _._,_._,_ >> >> > > -- > *ORIE STEELE* > Chief Technical Officer > www.transmute.industries > > <https://www.transmute.industries> >
Received on Saturday, 11 April 2020 02:07:01 UTC