- From: Adrian Gropper <agropper@healthurl.com>
- Date: Sun, 12 Apr 2020 17:11:11 -0400
- To: David Chadwick <D.W.Chadwick@kent.ac.uk>
- Cc: W3C Credentials Community Group <public-credentials@w3.org>
- Message-ID: <CANYRo8imcbRT7PH59wohiUyk33fjKXoCE2jYNAE0=TdgwqL4pA@mail.gmail.com>
IRL, medical verifiers like a pharmacist depend either on federation trough
their technology or Trust on First Use. The only time when credentials are
actually checked to their root, is when applying for a license in a new
state or some bigger hospitals.
Obviously, a driver's license with a biometric is not secret. A salted hash
of the biometric ID would might be a better link secret but I'm not sure
that helps much.
DID's don't sign anything but DID methods they promote non-repudiation
because they allow key management.
As far as test's being mediocre and constantly changing, that's why we need
a physician or expert to interpret them to issue the credential. Batch
numbers would certainly help but standardizing their use is a nice-to-have.
In a sane world, the interpretation of tests and symptoms. etc... would be
standardized by the WHO so that we could learn from communities and
countries that are hit before us. That, however is about politics, not
privacy.
- Adrian
On Sun, Apr 12, 2020 at 4:50 PM David Chadwick <D.W.Chadwick@kent.ac.uk>
wrote:
>
> On 13/04/2020 08:40, Dmitri Zagidulin wrote:
> > There's an important aspect that's missing from these schemas so far
> > -- the batch number (or even the individual ID) of the tests themselves.
>
> that is not missing from the VC that we use and that I circulated to the
> list earlier.
>
> I ran my proposed VC contents past some medics and they were happy with
> its contents.
>
> Kind regards
>
> David
>
> > Consider the tests that the UK gov't ordered recently, which turned
> > out to have a 10% positive and negative false rates, so they sent them
> > back, asked for refunds, and so on. There's many different sources of
> > the tests, many iterations within a source, and a difference between
> > the batches, even, and all those things have an effect
> > epidemiologically (once it turns out, for example, that a set of tests
> > has a too-high error rate, so those credentials have to be revoked, etc).
> >
> > On Sun, Apr 12, 2020 at 3:58 PM Orie Steele
> > <orie@transmute.industries> wrote:
> >
> > 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
> > <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 (#95)
> > <https://toolsCCI.groups.io/g/main/message/95>
> > > | Reply To Group
> > > <mailto:main@toolsCCI.groups.io
> > <mailto:main@toolsCCI.groups.io
> >?subject=Re:%20Re%3A%20%5BtoolsCCI%5D%20Example%20Immunoglobulin%20Detection%20Test%20Credential>
> >
> > > | Reply To Sender
> > > <mailto:eric@korsimoro.com
> > <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
> > <mailto:main%2Bowner@toolsCCI.groups.io>> |
> > > Unsubscribe
> > >
> > <https://toolsCCI.groups.io/g/main/leave/8139918/92991810/xyzzy>
> > > [info@verifiablecredentials.info
> > <mailto:info@verifiablecredentials.info>]
> > >
> > > _._,_._,_
> >
> >
> >
> > --
> > *ORIE STEELE*
> > Chief Technical Officer
> > www.transmute.industries
> >
> > <https://www.transmute.industries>
> >
>
>
Received on Sunday, 12 April 2020 21:11:43 UTC