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 10:00:05 +1200
To: main@toolsCCI.groups.io
Cc: Adrian Gropper <agropper@healthurl.com>, "W3C Credentials CG (Public List)" <public-credentials@w3.org>
Message-ID: <b2fb60ae-e99f-61db-7079-a48f30275646@verifiablecredentials.info>
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]
>
> _._,_._,_
Received on Sunday, 12 April 2020 22:00:33 UTC

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