W3C home > Mailing lists > Public > public-credentials@w3.org > April 2020

Re: [toolsCCI] Example Immunoglobulin Detection Test Credential

From: Orie Steele <orie@transmute.industries>
Date: Sun, 12 Apr 2020 14:57:35 -0500
Message-ID: <CAN8C-_LqRDm-xXmUBVVtJROqkkhJ=EMAVUyvih-Sei_we0CNqQ@mail.gmail.com>
To: "D.W.Chadwick" <info@verifiablecredentials.info>
Cc: main@toolscci.groups.io, Adrian Gropper <agropper@healthurl.com>, "W3C Credentials CG (Public List)" <public-credentials@w3.org>
I'm having trouble parsing paragraphs of text into requirements... Lets
avoid bluetooth / qr codes until we get these credential format fields
documented formally somewhere...

Let's describe the credential types using the VC Data Model terminology:
Issuer, Holder, Verifier, Subject, Claims, etc...

Let's describe each credential as a set of inputs and outputs...

Here are some assertions, we should probably get consensus on first:

Subjects will need to be tested multiple times...

TestSubject (Holder)
- Has internet access.
- Has identification card with image, type and number.

TestingFacility (Issuer of SampleCollectionCredential)
- Has a DID.
- Has internet access.
- Has website
- Has location, address / gps
- Can only issue a SampleCollectionCredential, a form of receipt that a
sample was collected and will be tested.
- Will not test someone who has no form of identification / contact
ability. (is this true?)

SampleCollectionCredential
- credentialSubject.id is hash of (subject identification card type and
number + 8-digit-pin)
- identification card type.
- testResultEndpoint (
https://example.com/covid-19/test/credentialSubject.id )
- expiration

TestingLab (Issuer of TestResultCredential)
- Has a DID.
- Has internet access.
- Has website

TestResultCredential
- credentialSubject.id is hash of (subject identification card type and
number + 8-digit-pin)
- IgM boolean
- IgG boolean
- expiration
- is publically accessible without any form of authentication (is this
true?)

TravelEnforcmentPerson (Verifier of Credentials)
- Has internet access.
- Can review identity documents
- Can verify credentials

I worry that assuming the subject will have a DID or be able to do anything
but present a bearer token to the verifier is an unreasonable assumption.

In order for a bearer token to be acceptable, it will need to be bound to
some identity system which includes an image.

Are we assuming the Subject / Holder has a DID or not?

OS



On Sun, Apr 12, 2020 at 1:56 PM D.W.Chadwick <
info@verifiablecredentials.info> wrote:

> Hi Eric
>
> Thankyou for your very detailed discussion below.
>
> A lot of your comments below are about the topic of "Attribute
> Aggregation", whereby the holder collects together attribute assertions
> from many different issuers and submits them either concurrently or
> sequentially to the verifier. I think this is the correct way to go for
> medical certificates of all kinds, since each attribute assertion (or
> VC) is independently collected by the user, each issuer acts
> independently of the others and does not need to know anything about the
> other issuers or the attributes they issue, and the *data model and
> protocol* should provide a mechanism whereby the holder can collect the
> set and prove possession of the entire set that he/she presents to the
> verifier.
>
> We implemented such a system many years ago for federated identity
> management using SAML, and Open ID Connect now supports this feature in
> its protocols (as does our COVID-19 Immunisation Certificate verifiable
> credential middleware). In our case the unifying feature is a transient
> public key in each assertion, and the holder signs the presentation to
> prove possession of the collection.
>
> As you say, we certainly should not be asking the user to remember yet
> another password. Such cognitive overload is unnecessary.
>
> Working offline as your require, it is impossible to achieve the above,
> because offline working does not allow transient identifiers to be used.
> Persistent IDs must be used in this case, and each presentation (big QR
> code) will be the same and contain the same linking ID, thereby losing
> some of the holder's privacy. But these sorts of trade-offs are
> necessary, as no system can provide all the most desirable features.
>
> So whether the linking id is transient or persistent will depend upon
> the use case.
>
> I would add that using persistent IDs with offline working introduces
> the added complexity of revocation. What happens when the paper QR code
> given to a person becomes invalid because a new strain of COVID-19 has
> arisen, meaning that their immunity is no longer valid. You might argue
> that you could build in blanket refusal to everyone with a similar
> immunity certificate, but this might be too blunt an instrument. It
> depends upon the science of immunity, of which I know nothing.
>
> kind regards
>
> David
>
> On 13/04/2020 04:02, Eric Welton (Korsimoro) wrote:
> >
> > My original concern about the proposed VC involved the linking of
> > id-proofing material with the medical data. For example
> > {
> >   { IgG...., nameData...., humanSexualityFields....,
> > schema.orgPersonDescriptions..... }
> > }
> > And this was replaced with the following model
> > {
> >   { IgG...., identityDocumentLinkData.....}
> >   { identityDocumentLinkData...., restOfIdentityData..... }
> > }
> > where identityDocumentLinkData included an "identity document type",
> > and a field value for the externally defined "primary key like field"
> > for that identity document type.  The example given was the highly
> > u.s. specific "Driving License", but could easily be extended to
> > include other identifying document, like national ids. This however,
> > introduces "low-value complexity" because of the need to have the
> > medical information model include a semantical model of allowable
> > identity-proofing documents - for example, are Saudi Arabian Iqama's
> > or Thai Resident Laborer Alien Cards ("Pink Cards") or United States
> > IR-visa cards acceptable?  Where is this registry maintained - because
> > it is required so that you can look up the appropriate "field name" in
> > the id-proofing data - either that or you start pulling even more of
> > the id-proofing metadata into the medical information.
> >
> > And what does this identity proofing data have to do with the raw
> > medical information?  All of this complexity can be avoided by simply
> > taking advantage of the adjacency of the credentialSubject material
> > and the fact that there is a unifying signature over that data - as in
> > {
> >  {.... medical information }
> >  {.... id-proofing data, "this is a <name of document type>" }
> > } => signature (or hash)
> >
> > This lets you focus on modeling the medical information independent of
> > the identity-proofing information, and lets the verifier, holder, and
> > issuer use the id-proofing information as is appropriate to the
> > context.  It does not mandate, for example, disclosure of a Social
> > Security Number to a medical testing lab.
> >
> > We also have a need to associate multiple pieces of medical
> > information, which are produced later - in different times and places
> > - with the identiity information.  For example - blood collected at a
> > medical intake facility might produce an initial record
> > (SampleCollectionCredential) like
> > {
> >  { linkCode = <collision-resistant-pii-free-identifier> }
> >  {.... medical information }
> >  {.... id-proofing data, "this is a <name of document type>" }
> > } => signature
> > where the medical information may be nothing more than a bar-code
> > printed on a label printer and attached to a test-tube, or may be more
> > sophisticated - as long as it is PII free.  Location, facility,
> > attendant and that sort of information is split across the medical
> > information and issuer identification as appropriate - or perhaps
> > there are other data blocks {.... facility information } or {....
> > weather conditions }, etc.
> >
> > At a later time, the above SampleCollectionCredential is used to
> > produce the following TestResultsCredential
> > {
> >  { .... linkCode }
> >  { .... second medical information }
> >  { .... third medical information }
> > } => signature
> >
> > where the lab facility and processing information is again split
> > between the issuer and the medical records - perhaps there are serial
> > numbers of re-agent lots or testing-kid GTIN/NTIN numbers, or any bits
> > of other data TBD.
> >
> > Importantly, no PII is used to link these records - it is an arbitrary
> > id, and not sha256(id-proofing-document-type,
> > id-proofing-document-primary-key-field-value,
> > 8-digit-one-time-use-passcode).  Use of a purely random collision
> > resistant identifier, like a UUID or public-key fingerprint, avoids
> > the problems inherent in id-proofing document meta modeling (which
> > require that we have a central registry of allowable id-proof types
> > and models which minimally allows us to identify the primary key field
> > in the id-proofing data model)...
> >
> > It also avoids placing the cognitive burden on the subject for
> > remembering yet another passcode - which they should probably write
> > down on whatever document is provided.  For example, a feasible way to
> > maintain reference to the data is through a couple of QR codes
> > pointing to cloud-backed storage of the information, such as
> > http://example.com/covid/collection/<linkCode>?password=12345678
> > with the later-produced lab results available at
> > http://example.com/covid/results/<linkCode>?password=12345678
> >
> > Importantly, the password is just encoded in the QR code, but
> > otherwise in plaintext.  If we force the user to memorize the
> > password, we should provide a way to to record the user's password and
> > allow them to recover it, as remembering "yet another series of random
> > digits" is very, very difficult.  Perhaps they could "store it in
> > their phone" as a fake phone number, or write it down on a little
> > sticker, or we can give them a password recovery password, which
> > itself would need a password recovery password recovery password,
> > which itself would need a ......  Perhaps we could let them
> > "authenticate with google" or use their facebook login to retrieve the
> > password automatically....
> >
> > The difficulty of supporting this password makes me want to step back
> > and look at the role it plays.  The need to restrict access to
> > information is *critical* when the medical information contains
> > personally identifying information, such as is the case in this model
> > {
> >  { medical information...., idType=texasDriversLicense,
> > idPrimaryKey="12345" }
> >  { detailed id-proofing information, idType=texasDriversLicense,
> > texasDepartmentOfPublicSafetyNumber="12345" }
> > }
> > and, the subsequent test results are modeled as
> > {
> >  { hashOfPII_and_Password }
> >  { test1Results..... }
> >  { test2Results..... }
> > }
> > but it is less of a concern when modeled as
> > {
> >  { <collision-resistant-arbitrary-pii-free-identifier> }
> >  { medical information.... }
> >  { detailed id-proofing information, idType=texasDriversLicense,
> > texasDepartmentOfPublicSafetyNumber="12345" }
> > }
> > and, the subsequent test results are modeled as
> > {
> >  { <collision-resistant-arbitrary-pii-free-identifier> }
> >  { test1Results..... }
> >  { test2Results..... }
> > }
> >
> > In the latter there is no strong connection between the source and
> > result data, but the connection is there and acceptance of it is a
> > matter of personal taste and the reality of the sponsoring agency or
> > health authority operating the initial point of medical contact and
> > testing.  Subjects should not trust any random person sitting in a
> > cardboard box under a bridge with collecting their blood and promising
> > they'll send it for testing - rather, there is some organization
> > making the outreach and contracting with testing labs.  It is *this*
> > organization which is in a position to provide some level of access
> > control, such as running the example.com <http://example.com> website
> > allowing subjects and policy enforcement officers to access the data
> > later on.
> >
> > In terms of "logging on to the lab website" rather than through the
> > example.com <http://example.com> website, is a secondary consideration
> > which may or may not make sense. In either case, the orchestrators of
> > the collection process have first-line access to id-proofing material,
> > and this material can be used to log in later - perhaps making use of
> > any of the numerous services that provide direct verification of
> > primary id-proofing documents. Alternatively, sponsoring organizations
> > are likely to require that users download an "app" for the devices
> > that manage those users, and use a "log in with facebook" model for a
> > web-site serving non-device managed people.
> >
> > The business concerns of that sponsoring organization, or of the lab's
> > business models should not influence the credential design - but they
> > do benefit from maximum separation of concerns within the credential
> > design.  This gives the most flexilibity and minimizes PII liability.
> >
> > Jurisdiction also plays a huge role - at MyData 2019 i saw a slide (I
> > am blanking on whose presentation) - but it listed three approaches to
> > data.  The american approach where data control belongs to businesses,
> > the chinese approach where data control belongs to the state, and the
> > european model where data control belongs to the individual.  The
> > organization supporting the testing and issuance, and any direct
> > access to results via the testing lab or 3rd parties,  will operate in
> > one of these contexts.  It is not the responsibility of the covid
> > credential model to take a position on this - rather it must remain
> > orthogonal to these concerns.  This means that ensuring individual
> > control over the use of the data is *not* in scope while making any
> > structure which *prohibits* control over the data must be avoided.
> >
> > What we must maximize is the independence of data points - maximize
> > the separation of concerns - because this and only this gives us the
> > flexibility we need to operate on a global scale.
> >
> > We also need to note that, while the initial { medical information...
> > } can be PII free, the following test results may or may not be PII
> > free - depending on the depth and detail of the test.  If the test is
> > only about "antibody present/absent" - then it is not PII sensitive,
> > but if it contained detailed analysis of a set of genetic markers such
> > that it was effectively a DNA fingerprint, then one might argue that
> > it was PII.  This influences the acceptability of the other components
> > and the risks inherent in the linkability of data - and it is
> > sensitive to your operating context.
> >
> > A great deal can be achieved in mitigating the current virus
> > distribution by supporting only low-PII rest results, and zero-PII
> > linking keys.
> >
> > Regardless of PII exposure in the testing pipeline - the verification
> > context we seek looks like this:
> >
> > /1. subject approaches policy enforcement officer and presents/
> > /1.1 - QR code (digital or analog)
> > /
> > /1.2 - original identity proofing document (digital or analog)
> > /
> > /1.3 - self (analog)
> > /
> > /2. policy enforcement officer..../
> > /2.1 - scans QR code and retrieves id-proofing data for
> > <collision-resistant-arbitrary-pii-free-identifier> (performing issuer
> > verification)
> > /
> > /2.2 - makes judgement call as to whether id-proofing matches, using
> > whatever tools are appropriate - this could include everything from a
> > checkpoint guard simply looking at the photo on their screen, along
> > with basic demographic data and then looking at the person in front of
> > them - or it could be more sophisticated, using biometrics ranging
> > from facial recognition to voice printing and fingerprints./
> > /2.3 - optionally requests some indication from the subject to
> > "release" the test results - but this is optional, and depends upon
> > the tooling available to the policy enforcement officer and the
> > subject and the context - this is roughly equivalent to the use of the
> > PIN, but could be expanded (if SSI enabled) to include consent
> > tracking (in situations where that is relevant)
> > /
> > /2.4 - retrieves the relevant test results (performing issuer
> > verification) and determines appropriate course of action - allowing
> > the subject to continue, blocking the subject, or detaining the subject/
> >
> > Note that the subject is almost entirely passive. The digital
> > signatures support the identification of the issuer - and that can
> > easily be tied in with existing PKI, where that exists, as well as
> > using DIDs if that works - this is determined by the policy
> > enforcement context.  Data could be presented by the subject either
> > digitally or analog, as is appropriate to the context. What we
> > generally do not need is the subject to engage in negotiation, or be
> > able to "forget a password" or otherwise hose up the policy
> > enforcement pipeline. Imagine how long it would take to get on the
> > subway if everyone had to "haggle" a ticket price - it is bad enough
> > using PIN based debit cards, which is why the typical subway access is
> > mediated by side-loaded stored-value systems - which excludes "putting
> > in a PIN" from the primary enforcement pipeline - this is the
> > sensibility we need to pursue.
> >
> > What is horrific about the above model is that the policy enforcement
> > is going to a central database that has "all the records" - that is
> > kinda what we want to avoid.  To avoid this we need to get a third
> > credential - and ideally one that is "fit for purpose" (e.g. tailored
> > to the policy enforcement need, and perhaps sponsored by/issued by
> > that agency) - or, alternatively, one that is generic - in which case
> > it should be offered by some common agency which is financially
> > supported by the policy enforcement agencies.
> >
> > Such a third party might be related to the same agency supporting the
> > testing tents and outreach - and the same considerations about
> > "logging in" apply.
> >
> > What is important is that these tertiary credentials can effectively
> > act like a zero-knowledge-proof or a ZCAP key.  For example - let's
> > imagine that I wanted to screen people at an inter-state border, only
> > allowing people to enter my state if they could prove that they had
> > recently been tested and are negative.  What I want at the border is a
> > very fast test with no network access - like scanning a "big QR code"
> > - it is easy to imagine a system with this verification strategy:
> > 1. subject approaches policy enforcement officer (or system) and presents
> > 1.1. self (stares into camera)
> > 1.2 qr code (holds up to camera)
> > 2. policy enforcement officer (or system)
> > 2.1 performs facial recognition between self and image encoded in qr
> > code and/or bound to id-proofing document
> > 2.2 checks that 'virus testing result' matches policy
> > 2.3 verifies issuer credentials
> > 2.4 makes policy decision (for example, raises gate and allows subject
> > to pass)
> >
> > This would be completely feasible - it has no network round trips so
> > there is no essential central honeypot of test results.  Furthermore,
> > the subject could (in jurisdictions with GDPR-like legislation)
> > request that any central records of the first stages be deleted,
> > meaning that the QR code (either on a sticker or in their phone or any
> > other device that manages them) is the only record of the data - yet
> > it was born with a chain-of-evidence and data-provenance which
> > provides strong indication of trustworthiness.
> >
> > You can also imagine that later, as this ecosystem matures, tertiary
> > credentials could be issued almost automatically - using the ever
> > improving systems that support online verification of the original
> > id-proofing document, along with liveness checks and strong
> > audio/visual biometrics - and this brings us to *SSI* and *cloud
> > agents*.  All of the above can be improved through the use of SSI
> > technology - be it either cloud-agents or edge-agents.  What is
> > essential is that the process is possible without SSI technology.  SSI
> > and private-key management must be an enhancement to this process, not
> > a requirement.
> >
> > Furthermore, SSI agents enable advanced control over the further uses
> > of testing associated information - where agents are understood
> > generically - perhaps they are Aires agents, or perhaps they are
> > HIE-of-one Trustees.  Until that infrastructure is ubiquitous and
> > business practices and policy enforcement endpoints are well poised to
> > make use of them, we must not require it.  We are building towards a
> > world where our solution looks like this
> > {
> >  {.... medical information }
> >  {.... did }
> > } => signature (or hash)
> > And where eventually we will use the service_endpoints of the DID to
> > answer every request for id-proofing data with the question "who
> > want's to know" and make a private-policy driven decision for
> > information release, therefore giving the individual control over all
> > exchanges of their health information - we just aren't there yet.  On
> > the other hand, this is a phenomenal opportunity for bootstrapping
> > that universe if we can find just the right way to sidestep the
> > chicken-and-egg problem.
> >
> > The only step that can be taken - at this point - is isolating, as
> > early as possible, PII from medical information and break from
> > traditional practices, which would use PII in place of
> > opaque-identifiers.  This is a significant step forward - as it is
> > extremely tempting to start out with data using structures like
> > {
> >  IgG...
> >  IgM...
> >  gender....
> >  firstName...
> >  lastName...
> >  address....
> >  mobileNumber...
> >  emailAddress...
> > }
> >
> > So - I think we can make a huge step forward using the technology we
> > have and deploying it in a way that works for DID and phone free
> > individuals, and supports  rapid, low cost, offline deployment in
> > front-line policy enforcement scenarios across all tiers of technical
> > capabilities.  We can achieve these goals with this model:
> > *Sample Collection Credential:*
> > {
> >  { linkCode = <collision-resistant-pii-free-identifier> }
> >  {.... medical information }
> >  {.... id-proofing data, "this is a <name of document type>" }
> > } => signature
> > *Test Results Credential:*
> > {
> >  { .... linkCode }
> >  { .... second medical information }
> >  { .... third medical information }
> > } => signature
> > and derive *Rapid Clearance Credentials* (QR encoding)  to facilitate
> > zero-network, minimal-PII, high quality, point-of-enforcement decision
> > making.
> >
> > This is something we have all the tools to deliver quickly. Maximal
> > separation of data concerns minimizes risk of abuse and can adapt to
> > worldwide conditions across a huge range of technical realities.  This
> > opens the door to improvement via SSI technology - specifically agents
> > and trustees, and sophisticated personal information wallets.
> >
> > best,
> >
> >  -e
> >
> >
> > On Sun, Apr 12, 2020 at 12:28 AM orie <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 <mailto: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 <mailto: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
> >                     <mailto: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
> >                         <mailto: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 <http://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
> >                                 <http://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>
> >
> >
> >
> >                     --
> >                     *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>
> >
> > _._,_._,_
> > ------------------------------------------------------------------------
> > Groups.io Links:
> >
> > You receive all messages sent to this group.
> >
> > View/Reply Online (#95) <https://toolsCCI.groups.io/g/main/message/95>
> > | Reply To Group
> > <mailto:main@toolsCCI.groups.io?subject=Re:%20Re%3A%20%5BtoolsCCI%5D%20Example%20Immunoglobulin%20Detection%20Test%20Credential>
>
> > | Reply To Sender
> > <mailto:eric@korsimoro.com?subject=Private:%20Re:%20Re%3A%20%5BtoolsCCI%5D%20Example%20Immunoglobulin%20Detection%20Test%20Credential>
>
> > | Mute This Topic <https://groups.io/mt/72913968/4526704> | New Topic
> > <https://toolsCCI.groups.io/g/main/post>
> >
> > Your Subscription <https://toolsCCI.groups.io/g/main/editsub/4526704>
> > | Contact Group Owner <mailto:main+owner@toolsCCI.groups.io> |
> > Unsubscribe
> > <https://toolsCCI.groups.io/g/main/leave/8139918/92991810/xyzzy>
> > [info@verifiablecredentials.info]
> >
> > _._,_._,_
>
>

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

<https://www.transmute.industries>
Received on Sunday, 12 April 2020 19:58:05 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 24 March 2022 20:24:58 UTC