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

Re: [toolsCCI] Example Immunoglobulin Detection Test Credential

From: D.W.Chadwick <info@verifiablecredentials.info>
Date: Mon, 13 Apr 2020 08:24:07 +1200
To: Adrian Gropper <agropper@healthurl.com>, Orie Steele <orie@transmute.industries>
Cc: main@toolscci.groups.io, "W3C Credentials CG (Public List)" <public-credentials@w3.org>
Message-ID: <2de3e8d6-873f-f32a-98f6-e54928566eab@verifiablecredentials.info>

On 13/04/2020 08:14, Adrian Gropper wrote:
> I'm assuming the Subject / Holder does not have a DID.

agreed. But rather than DID, the more important question is, does the 
holder have a key pair or not?

With FIDO2, the answer is yes. Every mobile phone user has an unlimited 
number of key pairs and does not even know it.

>
> Also, I'm assuming the Testing Lab has no DID either. There are 
> relatively few of them and they would have SSL certs and websites 
> accessible to the credential issuer (see below).
agree with all of the above.
>
> The Testing Facility may not need a DID as long as the lab they are 
> sending samples to trusts them out of band which is likely, because 
> they have to trust them for all sorts of other processes.

I would go further and say the Testing Facility does not need a DID. In 
fact no player in the system needs a DID.


>
> The only entity that may need a DID to *issue* a credential to the 
> subject is the expert that interprets the lab results + symptoms + 
> previous results + health records of the subject. This is likely 
> credentialed doctor or trained expert and they will have to sign the 
> credential in a non-repudiable way.

DIDs don't sign anything. Keys do.

Kind regards

David

>
> - Adrian
>
>
>
> On Sun, Apr 12, 2020 at 3:57 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 20:24:32 UTC

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