Re: [toolsCCI] Example Immunoglobulin Detection Test Credential

inline...

On Sat, Apr 11, 2020 at 6:06 PM Orie Steele <orie@transmute.industries>
wrote:

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

The context is getting through a door by showing the bouncer your phone the
way you might a driver's license. This is not like showing a boarding pass
to the gate agent because there's no pre-registration. The main issue in
this context, is whether the bouncer thinks you've borrowed somebody else's
license or tampered with your own license. There is no privacy issue as
long as the bouncer promises not to save any PII after he makes a decision
to let you in or not.

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

By the hash. The hash was generated by your wallet. The lab never sees the
actual driver's license.

The lab issues a VC to the hash that includes your test result.


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

I'm not sure about the salt. If I trust the verifier not to store the data
from my driver's license, I can let them calculate the hash (with salt) and
match it to the VC that was issued to the hash.

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

Not necessarily. The association between the sample and the driver's
license may be made by a nurse that draws the blood. The nurse saves
nothing but might sign the hash with her credentials in order to be held
accountable.

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

Yes, mostly. The result is accessed by the hash. This is similar to how
COVID bluetooth proximity schemes (Google and Apple announcement) are based
on pseudorandom rotating IDs that can only be re-identified by the issuing
app which is under the control of the subject (the wallet).

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

No. The lab has zero PII.



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

Yes.

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

Yes.

Thank you,
- Adrian

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