- From: Orie Steele <orie@transmute.industries>
- Date: Sun, 12 Apr 2020 17:09:40 -0500
- To: "D.W.Chadwick" <info@verifiablecredentials.info>
- Cc: main@toolscci.groups.io, Adrian Gropper <agropper@healthurl.com>, "W3C Credentials CG (Public List)" <public-credentials@w3.org>
- Message-ID: <CAN8C-_LM9+vpioBPbrUySPc0u3pvaRzWW8L7ZUC6O4XsN_vL7w@mail.gmail.com>
I tried to capture Daniel Hardman and Adrian's comments in Example 2 here:
https://github.com/w3c-ccg/vc-examples/pull/35/files
I'm assuming that we would setup everything that an issuer needed to do
their job, and their experience would be simple filling out forms.
There were some questions about the 8 digit pin...
Patients need to be given some small entropy secret (8 digits) on every
test, or we would be leaking metadata about a number of tests for a given
drivers license number or providing test results directly to anyone who has
ever processed a drivers license.
OS
On Sun, Apr 12, 2020 at 5:02 PM D.W.Chadwick <
info@verifiablecredentials.info> wrote:
> Hi Paul
>
> I can see how your schema applies to vaccinations, but not to immunity
> certificates
>
> Kind regards
>
> David
>
> On 13/04/2020 09:11, Paul Knowles wrote:
> > Hi all,
> >
> > I'm attaching a draft OCA schema spec for the "Immunization Passport".
> > I'm sure it will serve as a decent foundation for the final VC
> > construction. A screenshot of the current ICVP is also attached for
> > reference.
> >
> > An example of a Sovrin schema containing hashed payload and hashed
> > schema structure (deployed in a recent Novartis project) can be found
> > here <https://indyscan.io/tx/sovstaging/domain/81718>.
> >
> > In that example, the VC construct only contains 4 attributes:
> >
> > "credentialValidFrom" / "hashedPayload" / "payloadStructureID" /
> > "credentialValidUntil"
> >
> > [Note: "hashedPayload" represents a hash of the data (i.e. data
> > entry). "payloadStuctureID" represents a hash of the schema structure
> > used to capture the data (i.e. data capture)]
> >
> > Paul
> >
> > On Sun, Apr 12, 2020 at 10:39 PM D.W.Chadwick
> > <info@verifiablecredentials.info
> > <mailto:info@verifiablecredentials.info>> wrote:
> >
> > Hi Adrian
> >
> > here are a few comments on your model.
> >
> > On 13/04/2020 07:55, Adrian Gropper wrote:
> > > David,
> > >
> > > I'm working with a much simpler use-case where the
> > interpretation of
> > > all the lab tests, self-reported symptoms, and health records are
> > > reviewed by a physician who then issues a credential to the
> > subject as
> > > holder.
> >
> > This immediately raises the issue of scalability and trust in the
> > issuer
> > when there are hundreds of thousands of them. I discuss the topic of
> > delegation between issuers in my IEEE Communications Standards
> > (Dec 19)
> > paper which I believe I circulated to the list after Manu
> > announced the
> > IEEE special edition was published. But here it is again in case your
> > don't still have it
> >
> > Improved Identity Management with Verifiable Credentials and FIDO
> > https://kar.kent.ac.uk/80304/ <https://t.co/oULKKQS5WK?amp=1>
> >
> > But it is problem that credit card issuers have already addressed so
> > there are practical solutions in wide use today.
> > >
> > > The subject presents the credential (issued by the physician or
> > other
> > > expert) as a QR code along with showing the verifier their
> > biometric
> > > ID for in-person review. This is the same biometric ID that was
> > used
> > > to label the sample(s) to the labs. It is, in my mind the "link
> > > secret" but it's secret only if the people it's shown to don't
> > snap a
> > > picture of it.
> >
> > Your link secret is a persistent ID. Persistent IDs by their very
> > nature
> > are not secrets, since they are meant to be shared (unlike
> > transient ids).
> >
> > So your model has to assume that the biometric ID is a public ID much
> > like today's SSN is.
> >
> > Providing the biometrics are strong, with few false positives or
> > negatives, then this should not be a big problem, because even if
> > I know
> > your biometric ID I cannot fool anyone that I am you (except in the
> > false positive case).
> >
> > >
> > > Revocation (or freshness, because a verifier can simply have a
> > local
> > > policy for long a particular interpretation is valid depending
> > on the
> > > exposure context) aside, can we make this work if the holder and
> > the
> > > verifier are both off-line?
> >
> > I would say yes if the biometrics are good enough with acceptably few
> > false positives. But I don't think they currently are. And you would
> > need to configure the long list of trusted issuers into the
> > verifier for
> > offline use.
> >
> > Kind regards
> >
> > David
> >
> > >
> > > - Adrian
> > >
> > >
> > >
> > > On Sun, Apr 12, 2020 at 2:54 PM D.W.Chadwick
> > > <info@verifiablecredentials.info
> > <mailto:info@verifiablecredentials.info>
> > > <mailto: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>
> > > <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>
> > <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>>
> > > <mailto: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>> <mailto: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>>
> > > > <mailto: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>>
> > > > <mailto: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>
> > <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>
> > > > <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 (#99) <https://toolsCCI.groups.io/g/main/message/99>
> > | Reply To Group
> > <mailto:main@toolsCCI.groups.io?subject=Re:%20Re%3A%20%5BtoolsCCI%5D%20Example%20Immunoglobulin%20Detection%20Test%20Credential>
>
> > | Reply To Sender
> > <mailto:paul.knowles@humancolossus.org?subject=Private:%20Re:%20Re%3A%20%5BtoolsCCI%5D%20Example%20Immunoglobulin%20Detection%20Test%20Credential>
>
> > | Mute This Topic <https://groups.io/mt/72913968/4526704> | New Topic
> > <https://toolsCCI.groups.io/g/main/post>
> >
> > Your Subscription <https://toolsCCI.groups.io/g/main/editsub/4526704>
> > | Contact Group Owner <mailto:main+owner@toolsCCI.groups.io> |
> > Unsubscribe
> > <https://toolsCCI.groups.io/g/main/leave/8153977/92991810/xyzzy>
> > [info@verifiablecredentials.info]
> >
> > _._,_._,_
>
>
--
*ORIE STEELE*
Chief Technical Officer
www.transmute.industries
<https://www.transmute.industries>
Received on Sunday, 12 April 2020 22:10:11 UTC