Re: [toolsCCI] Example Immunoglobulin Detection Test Credential

I'm not sure the exact context but I think the following is equivalent to
what you are suggesting.

1. Testing facility draws blood from people with driver's licenses.
2. Testing facility labels samples with unique id = sha256(drivers
license + salt).
3. When I log into the lab (how? by email, phone number?, anybody can see
results?)... I can find the result of my test, which contains no PII, by
knowing my drivers license number and the salt.
4. When someone asks for my results, I can show them my drivers license and
disclose the salt, and the can go download the results themself, or confirm
that the results I provided have the same identifier... but I also need
them to believe that whatever I provided them has not been tampered with,
hence they also verify the VC.

There are a couple things combined in these which it's probably a good idea
to seperate.

1. VC Format (sample identifier is a deterministic function of an existing
identifier, and we trust the test facility to generate this).
2. VC is signed at the lab, not at the point of collection... so we trust
the lab, they are the issuer, and we trust them not to change the
identifier from the facility... the lab does not need any PII to do its
job... unless they provide a web portal to log in with pii.. if they just
disclose test results publically, then they don't need PII.
3. VCs are disclosed via some permission system (login)... not defined, but
I would assume sms / email / IAL Level 2... implies the lab needs PII. or
that the login mechanism is knowing a sample-id...
4. Presentation of the VC includes the disclosure of information which can
be used to bind an existing identifier (drivers license) to the rest
results...

VCs for tests that have to be retrieved from the lab are harder than ones
that come from a facility that just does everything, which is why i tackled
the easy case first... but I guess its probably much more realistic that
people would have to wait  / lookup their results.

OS



On Fri, Apr 10, 2020 at 9:06 PM Adrian Gropper <agropper@healthurl.com>
wrote:

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

-- 
*ORIE STEELE*
Chief Technical Officer
www.transmute.industries

<https://www.transmute.industries>