- From: Adrian Gropper <agropper@healthurl.com>
- Date: Sun, 12 Apr 2020 17:18:30 -0400
- To: Paul Knowles <paul.knowles@humancolossus.org>
- Cc: main@toolscci.groups.io, "W3C Credentials CG (Public List)" <public-credentials@w3.org>
- Message-ID: <CANYRo8ikDk4=DS-J52=nY5bQk3swEUCq+S8djaozz0JbfmgFKg@mail.gmail.com>
Hi Paul,
Great, but what I'm looking for is a schema for an "Immunity Passport". As
mentioned in another thread a minute ago, I'm hoping this schema is managed
at a global level by WHO or equivalent.
- Adrian
On Sun, Apr 12, 2020 at 5:11 PM Paul Knowles <paul.knowles@humancolossus.org>
wrote:
> Hi all,
>
> I'm attaching a draft OCA schema spec for the "Immunization Passport". I'm
> sure it will serve as a decent foundation for the final VC construction.
> A screenshot of the current ICVP is also attached for reference.
>
> An example of a Sovrin schema containing hashed payload and hashed schema
> structure (deployed in a recent Novartis project) can be found here
> <https://indyscan.io/tx/sovstaging/domain/81718>.
>
> In that example, the VC construct only contains 4 attributes:
>
> "credentialValidFrom" / "hashedPayload" / "payloadStructureID" /
> "credentialValidUntil"
>
> [Note: "hashedPayload" represents a hash of the data (i.e. data entry).
> "payloadStuctureID" represents a hash of the schema structure used to
> capture the data (i.e. data capture)]
> Paul
>
> On Sun, Apr 12, 2020 at 10:39 PM D.W.Chadwick <
> info@verifiablecredentials.info> wrote:
>
>> Hi Adrian
>>
>> here are a few comments on your model.
>>
>> On 13/04/2020 07:55, Adrian Gropper wrote:
>> > David,
>> >
>> > I'm working with a much simpler use-case where the interpretation of
>> > all the lab tests, self-reported symptoms, and health records are
>> > reviewed by a physician who then issues a credential to the subject as
>> > holder.
>>
>> This immediately raises the issue of scalability and trust in the issuer
>> when there are hundreds of thousands of them. I discuss the topic of
>> delegation between issuers in my IEEE Communications Standards (Dec 19)
>> paper which I believe I circulated to the list after Manu announced the
>> IEEE special edition was published. But here it is again in case your
>> don't still have it
>>
>> Improved Identity Management with Verifiable Credentials and FIDO
>> https://kar.kent.ac.uk/80304/ <https://t.co/oULKKQS5WK?amp=1>
>>
>> But it is problem that credit card issuers have already addressed so
>> there are practical solutions in wide use today.
>> >
>> > The subject presents the credential (issued by the physician or other
>> > expert) as a QR code along with showing the verifier their biometric
>> > ID for in-person review. This is the same biometric ID that was used
>> > to label the sample(s) to the labs. It is, in my mind the "link
>> > secret" but it's secret only if the people it's shown to don't snap a
>> > picture of it.
>>
>> Your link secret is a persistent ID. Persistent IDs by their very nature
>> are not secrets, since they are meant to be shared (unlike transient ids).
>>
>> So your model has to assume that the biometric ID is a public ID much
>> like today's SSN is.
>>
>> Providing the biometrics are strong, with few false positives or
>> negatives, then this should not be a big problem, because even if I know
>> your biometric ID I cannot fool anyone that I am you (except in the
>> false positive case).
>>
>> >
>> > Revocation (or freshness, because a verifier can simply have a local
>> > policy for long a particular interpretation is valid depending on the
>> > exposure context) aside, can we make this work if the holder and the
>> > verifier are both off-line?
>>
>> I would say yes if the biometrics are good enough with acceptably few
>> false positives. But I don't think they currently are. And you would
>> need to configure the long list of trusted issuers into the verifier for
>> offline use.
>>
>> Kind regards
>>
>> David
>>
>> >
>> > - Adrian
>> >
>> >
>> >
>> > On Sun, Apr 12, 2020 at 2:54 PM D.W.Chadwick
>> > <info@verifiablecredentials.info
>> > <mailto: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>
>> > <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> <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>
>> > <mailto: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> <mailto: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>
>> > > <mailto: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>
>> > > <mailto: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> <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>
>> > > <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 (#98): https://toolsCCI.groups.io/g/main/message/98
>> Mute This Topic: https://groups.io/mt/72913968/4425499
>> Group Owner: main+owner@toolsCCI.groups.io
>> Unsubscribe:
>> https://toolsCCI.groups.io/g/main/leave/8108729/1481696610/xyzzy [
>> paul.knowles@humancolossus.org]
>> -=-=-=-=-=-=-=-=-=-=-=-
>>
>>
Received on Sunday, 12 April 2020 21:19:03 UTC