Fall 2021: COVID vaccination acceptance criteria across the world are inconsistent. An independent 3rd party criteria evaluator solves this using a different approach to “Zero-Knowledge Proof”.
List of Contributors
- Neil Thomson – QueryVision
- Paul Knowles, Robert Mickwicki – Human Colossus Foundation
- John Walker – Semantic Clarity
Executive Summary
In principle, Verified Credentials (VCs) are standardized so that a VC for COVID-19 health status (status = vaccinated or negative test or positive anti-bodies) is accepted by all jurisdictions. However, in the July/Aug 2021 timeframe, most provincial, state, continental and national jurisdictions are defining incompatible acceptance criteria. While this lack of compatibility may resolve over time, it is the current reality and will probably repeat in other VC domains.
With the currently defined Issuer/Holder/Verifier interaction, supporting different acceptance criteria per jurisdiction requires some potentially undesirable solutions. Two examples:
- Generation of jurisdiction-specific VCs from potentially multiple Issuers for travel
- Verifiers making requests for richer credential data (with Holder consent) for the Verifier to use jurisdiction-specific evaluation criteria, which significantly increases the potential for private data exposure and capture by “bad actors.”
The credential data required for the different acceptance criteria reviewed was 95% common. The evaluation criteria reviewed could be supported by a combination of standard data queries and procedural logic.
It is proposed to use a “rules engine,” ideally as a separate component (Verifiable Claim Evaluator or VCE) in the Issuer, Holder, Verifier, Ledger VC workflow, to provide an independent, 3rd party evaluation.
The VCE acts as a “Digital Notary (or Notary Public)” in that it is an entity certified and trusted by Governance Authorities and processes private and sensitive information, rendering a result, while protecting the client’s (Holder’s) privacy.
The Verifier presents the evaluation criteria (Claims Expression) to the VCE, and the Holder presents credential data to the VCE.
The VCE executes the expression against the data and returns the result and execution log to the Verifier and Holder. Ideally, the result is a simple pass/fail.
This solution provides a path to a single VC, where Verifiers can apply different evaluation criteria against VC credential data that is transparent, secure, and preserves data privacy.
Problem
The reality of COVID-19 vaccines, tests and acceptance across countries, states and provinces is much more complex in August-2021 than anyone expected in August-2020. There are 21 vaccines “approved” for emergency use somewhere in the world and more in development. However, in many countries, only two or three vaccines have been approved by their federal health authority, biased towards vaccines manufactured within their borders.
Different jurisdictions are currently basing what they will accept from international travellers, primarily based on their own local public health policies. Some specific examples:
- US Center for Disease Control (CDC), Cruise Lines (& others following CDC)
- Only Moderna and Pfizer vaccines
- No mixing of vaccines (e.g., two shots: AstraZeneca, followed by Pfizer – widely practiced in Canada, Spain, UK, …)
- France
- AstraZeneca, but not if manufactured in India
The good news is that the capture of vaccine and test manufacturing data, plus what is recorded at the time of vaccination or administering an infection or recovery test, is being driven by a worldwide convergence on medical data structure, of which the Fast Healthcare Interoperability (FHIR) schema(s) is a leading example.
A substantial problem, which is outside the scope of this paper, is that there is little agreement on technical (smartphone) and non-technical (paper) solutions for presenting VCs are accepted (in general and COVID-19 related VCs in particular), even within borders.
The vaccine/test/recovery use cases, which have been a driver for VC design and implementation for the last 18 months, defined assumptions/goals, which have culminated in the Good Health Pass.
- Vaccines and tests approved and administered in one jurisdiction will be accepted in others.
- The ideal privacy-preserving VC presentation and acceptance criteria (across jurisdictions) is:
- Vaccination status or Anti-body/recovery test status: pass
- COVID-19 infection test status: negative
- If the Verifier requires more data, it can request consent from the Holder for access to some or all of the VC credentials (and their data), for which it can apply jurisdiction-defined evaluation criteria.
Some observations on these assumptions, based on the recent acceptability decisions outlined earlier.
1 – Universal COVID-19 vaccine/test/recovery interoperability is a policy (political) problem that technology cannot solve and suggests this may not be true, even long-term.
2 – 1+2 Is conceptually the correct answer but is not being adopted across enough leading jurisdictions to become the worldwide standard, which, again, may not be true even in the long term.
- One solution would be to have VCs Issued for each jurisdiction, with jurisdiction-specific evaluation criteria embedded with the VC. This addresses the data privacy issues of point 3 (below)
However, this leads to an explosion of VCs across jurisdictions and the potential problem of different jurisdictions only accrediting Issuers within their jurisdiction (which creates a nightmare for travellers). - The GHP “Pass” fails to be privacy-preserving as name and date of birth are included along with pass/fail
3 – Has several privacy and transparency issues
- The Verifier may legitimately require some Personal Identifiable Information (PII) or other sensitive personal data to do their evaluation. However, there is no guarantee that the Verifier will not identify or re-identify the Holder with that data or record it for future use.
- The Verifier, in the current workflow, is opaque to how it uses the credential data. No mechanism exists to present how they will evaluate the data during the acceptance of the VC, nor is there a governance mechanism defined to ensure fair and equitable evaluation.
Scenarios/Use Cases
Note: while other use cases could be added to support the idea of a 3rd party evaluation rules engine, the GHP use case(s) are (at least initially) strong enough on their own for this Position Paper.
Non-Technical Requirements (Business, User)
The VCE’s role is to be an intermediary between the VC Holder and Verifier to process a VC held by the Holder to provide either:
- Evaluation of a VC’s claims to a Verifiers criteria (health status)
- Repackage VC claims to a Verifier’s schema requirements
Note: In many ways, a VCE supports a Verifier-controlled version of VC presentation (vs. the existing Issuer/Holder centric model). This could also be viewed as an example of a Smart Contract
Its role is to accept data (VC & claims) from the Holder and either an evaluation criteria or transformation expression against that data from the Verifier and returns a defined result without revealing PII or sensitive data.
What the Verifier can request is subject to governance. The Verifier cannot request the return of PII or sensitive data, either barred by jurisdictional governance (can’t ask for birthdate or criminal records), or, where allowed by governance, without consent of the Holder
Solution
Assumptions:
- A VClaim Evaluator (VCE) is a component that is an intermediary in the Holder/Verifier workflow which acts as a proxy in both directions. The VCE
- Intercepts requests or responses between Holder and Verifier where it plays an active role
- Acts as a transparent proxy. For example, establishing authentication, authorization and trust between the Verifier and Holder
The APIs and protocols of the Holder/Verifier workflow are retained, with extensions and possibly alternate APIs to support the model (design and implementation detail).
- The Issuer issues a VC to the Holder which contains a relatively rich set of claims data that includes all the data required during evaluation by any arbitrary evaluation of a certain type (e.g., Good Health Pass). In the case of the GHP, the claims data is a superset (vs. a minimal set) of COVID-19 vaccination, infection and antibody test data.
- A Verifier has created an evaluation expression as a file and stores and registers it (with a signature) on the ledger.
- The expression could be a JSON or XML definition or an executable (e..g., JavaScript, Python)
- The expression returns a JSON object which can contain results from the evaluation.
- The expression must be available in human-readable form and must be signed via a crypto hash of the contents
- To meet the needs for evaluation expression capability in the known use cases, the evaluation (rules) engine must be capable of:
- Basic query capability and on the VC credential data
- Procedural logic on the returned data (e.g., to determine a pass/fail status) and crafting a JSON response
Workflow
- A Holder makes are quest to the Verifier (request to approve Global Health Pass)
- The Verifier requests a VCE sandbox to instantiate a VCE of a specified type (and possibly version), establishing trust and validating that the VCE is certified and the right version, etc. and registers its result endpoint with the VCE
- The Verifier and Holder establish trust
- The Verifier notifies the Holder that it will use “proof by VCE” plus a reference to the VCE.
- The Holder registers its result endpoint with the VCE
- The Verifier makes a “VCE proof” request to the VCE, with the following parameters:
- Reference to the evaluation expression (on the ledger)
- The VC required from the Holder
- (optional/TBD) an expression tailored request for the VC claims data required
- The VCE
- Requests the expression from the ledger and verifies it
- Asks for the Holder for consent the relevant VC credential data
- The Holder
- Evaluates and responds (consents) to the VC credential data request and returns the data via a container (e.g. ACDC) to the VCE
- The VCE
- Issues a consent receipt
- Evaluates the Verifier expression
- Returns the results and audit log of the evaluation to both the Verifier and Holder
Pros, Cons and Vulnerabilities
- Pros
- Allows arbitrary expressions against a known VC credential data model/schema
- Drives agreement on a single VC credential data schema (which may be easier to attain than agreement on VC acceptance criteria
- Privacy-preserving – supports access to PII and sensitive data for evaluation without revealing that data outside the VCE
- Provides transparency on how VC acceptance criteria are evaluated and an audit
log
- Cons
- Requires more credential data to be included in a GHP VC than the current model.
- Assumes agreement on a common VC Credential data schema.
- Cannot address the “political” problem of Country X not accepting VC credential data from Country Y (which is also true of the current GHP model)
- Vulnerabilities
- Subject to abuse without enforced governance
Solution Requirements
Governance:
- All VCEs (and likely all components of this type) must be a validated and approved component, evaluated by a governance authority or authority certified agent/agency
Component Security:
- The VCE must be a “sibling” to the Holder and Verifier in terms of protocols, trust exchange, authentication and authorization, signing requirements, etc. conceptually, but may have design and implementation differences due to functionality.
- The VCE must be signed, including a cryptographic hash of its executable to ensure no tampering.
Data Privacy provisions:
- A VCE Is a temporary object which is instantiated on request and is “destroyed” on completion:
- Execution environment – ideally executes in a 3rd party “sandbox”
- Lifetime – released on completion of an evaluation
- Data Access – No write access to persistent storage (may have internal cache)
- Access to the component is via API calls to provide inputs and retrieve results (errors, state/status)
- Evaluation results are returned to participating parties (Holder and Verifier, but could be others) which must register callbacks to receive API output and audit logs
Technology:
- The technology and evaluation expression language, syntax and format for the evaluation engine are entirely open.
- It is desirable that for a given Rules Engine that uses expressions for a given purpose, that there are standards such that multiple VCEs (or other “Rules Engines”) can fill the same role. Inversely it would be useful for Rules Engines for different purposes could use the same language/syntax/format (e.g., JavaScript)
COVID-19 VC evaluation capabilities:
- The evaluation (rules) engine must support procedural logic and generate (and consume) data/query requests via APIs in a web environment, including against DDE Data Containers (e.g. ACDC)
Other ToIP areas impacted
<TBD>
Resources & References
- Fast Healthcare Interoperability Resources (FHIR)
- Good Health Pass (GHP)
- Issuer/Holder/Verifier model
- Trinsic Basics – the Verifiable Credential Model
- Self-Sovereign Identity – book Alex Preukschat and Drummond Reed
- What is Personally Identifiable Information?
- Verified Credentials model