Re: [toolsCCI] Example Immunoglobulin Detection Test Credential

Yes.

The main issue for me is driving adoption of SSI by reducing the kinds of
actors that need to do something different. Specifically, this example says
that only the person drawing the sample (or the Testing Facility itself)
needs to have a DID and a digital wallet. Everyone of the other actors
(subject, lab, gatekeeper) has no new software or SSI.

This proposal, by the way, is a simplification of the Prescription Use Case
https://w3c-ccg.github.io/did-use-cases/#prescriptions-healthcare We (HIE
of One) could use some help modifying our reference implementation
https://youtu.be/Jv9ATXvP-sU to demonstrate this test credential
application.

- Adrian



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

> Based on feedback from Daniel Hardman and Adrian's comments, I'm planning
> on implementing a new ImmunoglobulinDetectionTest schema.
>
> The first format was aimed at anyone with a face, and assumed a cassette
> test and that the credential subject has a DID.
>
> There pros and cons to that approach... the most obvious con is that
> absolutely nobody has DIDs.
>
> I like the idea of splitting up the sample collection part and rest
> results part into 2 credentials, and using existing identifiers and hashing
> to link them.
>
> Here would be the new user story:
>
> 1. Subject drives up to a tent in a parking lot.
>
> 2. Testing Facility Checks some id ( "presentedIDType: a picklist with
> strings such as "drivers license", "passport", "national ID card", etc " )
>
> 3. Testing Facility Collects blood sample and issues a
> "SampleCollectionCredential"
>
> subject = sha256 ( presentedIDType + presentedIDNumber + 8-DIGIT-PIN )
> presentedIDType (repeated in credential)
> testResultURL: https://example.com/covid-19/vc-test-results/ ( subject )
>
> credential is provided on paper, to the subject after sample is taken
> (multiple copies are provided, and it's safe for them to be copied further).
>
> 4. sample get sent to lab... days go by, etc...
>
> 5. Subjects can check a registry for their test results, when test results
> are ready they are published at a URL, which is provided to them in their
> credential.
>
> testResultURL: https://example.com/covid-19/vc-test-results/ ( subject )
>
> 6. Subject can present test results to TSA / Law Enforcement when
> traveling by presenting their "SampleCollectionCredential" , whatever ID
> type they used for it, and disclosing their 8 DIGIT PIN
>
> 7. Verification is as follows
> 7.1 confirming the face / gender / eyes / height (etc) of the ID Card used
> for "SampleCollectionCredential"
> 7.2 Verify "SampleCollectionCredential" (no VP here, since the subject has
> no keys / DID).
> 7.3 Confirm  subject = sha256 ( presentedIDType + presentedIDNumber +
> 8-DIGIT-PIN ) (website helps them do this)
> 7.3 Lookup testResultURL: https://example.com/covid-19/vc-test-results/ (
> subject )
> 7.4 Verify "SampleTestResultCredential"
> 7.5 Apply allow / deny list (any other business logic rules)
>
>
> Only the issuers would have DIDs in this scenario, and there would be no
> signed verifiable presentations.
>
> anyone with presentedIDType + presentedIDNumber + 8-DIGIT-PIN, could claim
> a test result belonged to them, and its the responsibility of the verifier
> to check the presentedIDType.
>
> Assuming that the presentedIDType where digital and
> that SampleCollectionCredential were digital, a Presentation that included
> the disclosure of the 8-DIGIT-PIN could be made over any transport that was
> supported ( CHAPI / DIDComm / Bluetooth )
>
> OS
>
>
>
>
>
>
>
>
>
>
> On Sat, Apr 11, 2020 at 5:40 PM Adrian Gropper <agropper@healthurl.com>
> wrote:
>
>> 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>
>>>
>>
>
> --
> *ORIE STEELE*
> Chief Technical Officer
> www.transmute.industries
>
> <https://www.transmute.industries>
>