Re: [toolsCCI] Example Immunoglobulin Detection Test Credential

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>
>