This group is locked. No changes can be made to the group while it is locked.
Re: Example Immunoglobulin Detection Test Credential
|
Eric Welton (Korsimoro) <eric@...>
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 athttp://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 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 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. best, -e On Sun, Apr 12, 2020 at 12:28 AM orie <orie@...> wrote:
|
|
|