         

The Good Health Pass
Interoperability Blueprint
Approved Deliverable of the Interoperability Working
Group for Good Health Pass
Version 1.0.0 — August 1, 2021

The Good Health Pass Interoperability Blueprint

1

Table of Contents
Notices...................................................................................................................... III
Table of Figures........................................................................................................ IV
1 The Problem We Are Solving: Reopening Global Travel...................................... 1
1.1 The Challenge Of Health Data Exchange Across Ecosystems...............................3

2 The Good Health Pass Interoperability Blueprint...............................................5
2.1 Our Approach To A Good Health Pass......................................................................5
2.2 Key Design Choices....................................................................................................6

3 Where Does the Blueprint Fit Within the Industry?..........................................10
3.1 Good Health Pass Ecosystem................................................................................. 10
3.2 Integration With Open Standards............................................................................11
3.3 Building A Community Consensus......................................................................... 12

4 Solving for Interoperability: An Overview of the Blueprint.............................. 13
4.1 Next Steps Beyond the Blueprint........................................................................... 16

5 Overall Recommendations.................................................................................. 17
5.1 Recommendation #1: Consistent User Experience.............................................. 18
5.2 Recommendation #2: Security, Privacy, and Data Protection............................ 31
5.3 Recommendation #3: Identity Binding................................................................. 46

6 Credential Recommendations........................................................................... 60
6.1 Recommendation #4: Standard Data Models and Elements.............................. 61
6.2 Recommendation #5: Credential Formats, Signatures, and Protocols............. 69
6.3 Recommendation #6: Offline Paper Credentials.................................................. 81

7 Operational Infrastructure Recommendations................................................ 95
7.1 Recommendation #7: Rules Engines..................................................................... 96
7.2 Recommendation #8: Trust Registries................................................................102
7.3 Recommendation #9: Governance and Trust Frameworks.................................113

Appendices.............................................................................................................122
References..................................................................................................................... 123
Glossary..........................................................................................................................131
Acknowledgements....................................................................................................... 155
The Good Health Pass Interoperability Blueprint

IAppendix A: Example User Flows for Obtaining a Health Pass..............................156
Appendix B: COVID-19 Credentials Initiative (CCI) Schema
Task Force Data Specification Repositories....................................... 158
Appendix C: OCA Background................................................................................... 159
Appendix D: FHIR-OCA Data Pipeline....................................................................... 161
Appendix E: About the Good Health Pass Collaborative........................................ 162

The Good Health Pass Interoperability Blueprint

IINotices
The Trust over IP Foundation’s Interoperability Working Group for Good Health Pass (the “Project”)
would like to receive input, contributions, suggestions and other feedback (“Contributions”) on thespecifications, documents, source code, data, and other artifacts being developed within its working
groups (the “Materials”). By contributing comments to the draft, you (on behalf of yourself if you are
an individual and your company if you are providing Contributions on behalf of the company) grant the
Project under all applicable intellectual property rights owned or Controlled by you or your company anon-exclusive, non-transferable, worldwide, perpetual, irrevocable, royalty-free license to use, disclose,
copy, publish, license, modify, sublicense or otherwise distribute and exploit Contributions you provide
for the purpose of developing and promoting the Materials and in connection with any product that
implements and complies with the Materials. You warrant to the best of your knowledge that you haverights to provide these Contributions, and if you are providing Contributions on behalf of a company,
you warrant that you have the rights to provide Contributions on behalf of your company. You also
acknowledge that the Project is not required to incorporate your Contributions into any version of theMaterials. You further agree that you and your company will not disclose it or distribute drafts of the nonpublic Project Materials to third parties. Unless the parties agree otherwise or the Project Materials are
made publicly available by the Project, this obligation of non-disclosure will expire five (5) years from thedate the material was disclosed to you.

Source CodeAny source code you provide to the Project is subject to the Developer Certificate of Origin version 1.1,
available at http://developercertificate.org/ and the license indicated in the Project’s source repository
for the Materials.

Copyright Notice
Copyright © 2021, Trust over IP Foundation.
THESE MATERIALS ARE PROVIDED “AS IS.” The parties expressly disclaim any warranties (express,
implied, or otherwise), including implied warranties of merchantability, non-infringement, fitness for aparticular purpose, or title, related to the materials. The entire risk as to implementing or otherwise using
the materials is assumed by the implementer and user. IN NO EVENT WILL THE PARTIES BE LIABLE
TO ANY OTHER PARTY FOR LOST PROFITS OR ANY FORM OF INDIRECT, SPECIAL, INCIDENTAL, OR
CONSEQUENTIAL DAMAGES OF ANY CHARACTER FROM ANY CAUSES OF ACTION OF ANY KIND WITHRESPECT TO THIS DELIVERABLE OR ITS GOVERNING AGREEMENT, WHETHER BASED ON BREACH OF
CONTRACT, TORT (INCLUDING NEGLIGENCE), OR OTHERWISE, AND WHETHER OR NOT THE OTHER
MEMBER HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

LicenseThe Project is made available by the Joint Development Foundation. The current Working Group charter,
which includes the IP policy governing all working group deliverables (including specifications, source
code, and datasets) may be found on page 20 of this link.
Currently, the licenses governing the Interoperability Working Group for Good Health Pass deliverables are:Copyright mode: Creative Commons Attribution 4.0.
Patent mode: W3C Mode (based on the W3C Patent Policy).
Source code: Apache 2.0.
The WG is not expected to produce source code.

Living Links
Links to items referenced in the Good Health Pass Interoperability Blueprint, and materials developed tosupport its implementation, can be found on this Trust over IP Foundation Interoperability Working Groupfor Good Health Pass wiki page.
The Good Health Pass Interoperability Blueprint

IIITable of Figures
Figure 1: Good Health Pass Principles................................................................................ 2
Figure 2:  Good Health Pass Terminology............................................................................ 6
Figure 3:  The Good Health Pass Ecosystem......................................................................10
Figure 4:  Identity binding and authentication zones in the Good HealthPass ecosystem.................................................................................................. 20
Figure 5:  Identity binding and authentication zones in the Good HealthPass ecosystem.................................................................................................. 47
Figure 6:  Vaccination card..................................................................................................51
Figure 7:  The four core terms for describing data containers for health data
used for travel..................................................................................................... 62
Figure 8:  Health certificates and credentials that are not GHP-compliant
can all be used as inputs to generate a GHP-compliant healthpass (or travel pass)........................................................................................... 70
Figure 9:  Holder authentication to a FHIR-enabled health record systemusing OAuth 2 and OIDC...................................................................................... 71
Figure 10: A zero-knowledge proof credential can support dynamic
generation of any number of context-specific GHP-compliant
passes...................................................................................................................73
Figure 11:  When an issuer or holder cannot support BBS+ credentials, a
static Ed25519 credential can be used (either digital or paper),but it does not support selective disclosure......................................................75
Figure 12: Subsystem view of Rules Engine Processes..................................................... 97
Figure 13: Conceptual overview of the Good Health Pass digital trust
ecosystem showing the core role of a trust registry.......................................103
Figure 14: The peer trust architecture of the GHP decentralized PKI............................ 104
Figure 15: Direct issuers of GHP-compliant health passes MUST use
GHP-compliant trust registries. Issuers non-GHP healthcredentials are encouraged to use GHP-compliant trust
registries but may use other trust registry solutions that can beverified by GHP-compliant health pass issuers.............................................. 104
Figure 16: If supported in a specific EGF, a holder’s digital wallet can query
the trust registry for that ecosystem to verify that a verifier isauthorized......................................................................................................... 108

The Good Health Pass Interoperability BlueprintIVFigure 17:  The four layers of governance in the ToIP stack for decentralized
digital trust infrastructure................................................................................. 113
Figure 18: Class/instance relationships are inheritance, not hierarchy......................... 115
Figure 19: The class/instance relationships of general and specific EGFs..................... 115
Figure 20: The relationship of the GHP EGF as a general ecosystem governanceframework and the specific EGFs that conform to it...................................... 116
Figure 21: The four stages of development of governance for the Good
Health Pass digital trust ecosystem................................................................. 118
Figure 22: Governance Matrix............................................................................................ 121
Figure 23: Overlay Stack.....................................................................................................159
Figure 24: Semantic Data Pipeline..................................................................................... 161

The Good Health Pass Interoperability BlueprintV1

The Problem We Are Solving: Reopening
Global Travel

For more than a year, countries around the world have adopted various restrictions on mobility andpublic gatherings to prevent the spread of COVID-19 and prevent further strain on overburdened medical
systems. While necessary and appropriate to protect public health, the economic consequences of these“lockdowns” have been staggering.
The COVID-19 pandemic has impacted every segment of the economy. Especially hard hit has been thetravel and tourism sector. Representing 10 percent of global GDP, the sector is experiencing its single
greatest shock since the terrorist attacks against the United States on September 11, 2001.
z Between January and October (2020), international tourist arrivals were down 72 percent;z In 2020, the airline industry was expected to lose upwards of $118.5 billion USD, with additional
losses expected in 2021; andz In 2020, travel and tourism sector contributions to global GDP decreased by 49.1 percent – $4.5
trillion USD – nearly 18 times the impact felt during the 2009 global financial crisis.
z Employment in the travel and tourism sector decreased by 18.5 percent, a loss of 61.6 million jobs
worldwide.
Faced with competing demands to restore mobility and economic activity, and protect public health,there is a growing consensus that the best route forward is one in which the global economy – andinternational travel – is restarted incrementally in a manner that keeps transmission in check. To that
end, governments, employers, educational institutions, airlines, sports and event venues, and others are
considering whether they might require proof of COVID-19 status (vaccination, negative test, or recovery)
as a supplement to continued social distancing and masking requirements.
Such proposals, where individuals may be requested to share health-related data, raise genuine concerns
about individual data privacy rights. While centralized registries of individuals’ vaccine status or test
results often underpin public health surveillance, they also carry significant risk of data theft, could
facilitate problematic surveillance tactics, or inappropriately expose personal data, thus requiring adelicate approach to balancing public health and data security. Additionally, if not carefully implemented,
limiting entry based on health status could prove inequitable and poses the risk that individual liberties,
such as freedom of movement, freedom of association, and free choice of occupation, will be arbitrarily or
discriminatorily restricted.
In addition, this exchange of health data raises technical and regulatory challenges:z Existing paper-based credentials – such as the WHO “yellow card,” the U.S. Centers for Disease
Control and Prevention COVID-19 vaccination certificates, NHS COVID-19 vaccination cards and lab
test results – are easy to lose, prone to counterfeiting, and unnecessarily expose sensitive personal
informationz Health data may move outside of the highly regulated and controlled healthcare sector (i.e. healthproviders, public health authorities, private medical providers, lab testing companies) to a wide
variety of organizations in the travel and tourism sectors (i.e. airlines, border agencies, hotels, cruiselines) that may be unaccustomed or ill-equipped to manage sensitive health data, or who may havefinancial incentives to sell personal health information.
z Healthcare data exchange standards were designed for healthcare use cases and for exchange
between regulated entities, and not for the wide variety of use cases, business processes, andorganizations required to reopen economies and restart global travel. The lack of familiarity ofhealthcare standards outside of the sector in question, and the complexity that will arise fromapplying them to non-healthcare use cases, will further increase implementation challenges.

The Good Health Pass Interoperability Blueprint1

z Data exchange across sectors will need to work within existing (and complex) business processes,
integrate with existing (and often, incompatibile) digital infrastructure, and address differing
priorities.
At present, there is growing momentum: programs are in use, or being implemented, in many countries
around the world, including countries in the European Union, Israel, and Singapore. Additionally, many
companies across the travel and tourism industry, as well as concert venues and sports stadiums, havepublicly announced plans to use proof of vaccination or testing as a condition for entry.
The sense of urgency is palpable; everyone is looking for solutions that can help equitably and safely
reopen our global economies. But the urgency to adopt and implement digital health pass systems risks
creating a patchwork of systems that are not interoperable with one another, and that vary greatly interms of privacy, security, and user control over personal data. Further, the absence of coherent standards
makes it difficult for implementers, policymakers, and the public alike to understand the utility — andaccompanying risks — of such systems. This level of uncertainty also risks creating tremendous delays inthe traveler process flow of check-in, security checks and boarding operations.
The Good Health Pass Collaborative (GHPC) was born out of this urgency — to weave together existing
efforts and present a path toward “good” digital health passes built on key fundamental principles (asoutlined in the first white paper, entitled, Good Health Pass: a Safe Path to Global Reopening).
Inclusion

Societal

ChoiceOpen

Urgency

Principles of good
health passInteroperable

Privacy

Extensible
Trust
Control

Figure 1: Good Health Pass Principles
The GHPC brought together organizations with a shared sense of responsibility to ensure that, if theexchange of health status information is required, health passes respect the rights of the individual firstand foremost, appropriately balancing the data requirements of community health with the privacy rightsof the individual. The GHPC has come together to help:z Restore Confidence:Restoring international travel requires restoring confidence: the confidence oftravelers that they can move about without significant risk, the confidence of businesses that they

The Good Health Pass Interoperability Blueprint2

can resume normal operations without exposing their staff or customers, and the confidence ofgovernments that they can adequately protect the health of their citizens. Digital health passes offera route to reopening that can instill such confidence.
z Promote Equity: It is expected to take years to vaccinate the world’s 7.9 billion people. Widespread
testing is an essential public health tool – and one that must continue to be supported alongside
vaccination to ensure an equitable return to public life.
z Foster Collaboration: Numerous efforts are currently underway to develop data sharing andexchange solutions– both vaccination and test certificates – for international travel and a variety
of other applications. Given this, it is unlikely that a single solution will be implemented universally– or even across the entire travel industry. Thus, it is critical that solutions are designed to beinteroperable, both with one another and across institutional and geographic borders.

1.1 The Challenge Of Health Data Exchange
Across Ecosystems
By definition, proposals to use proof of health status as a condition of entry straddle multiple ecosystems
and will require that data exchange works within existing business processes, digital infrastructure andregulatory frameworks.

1.1.1

The Current Health Data Landscape

Healthcare systems vary radically across the world. In many countries, COVID-19 vaccination is being
coordinated almost entirely through public health authorities or national health systems, leading toa relatively small list of organizations (or singular entity) able to attest to an individual’s vaccination
status. In some countries, testing is similarly centralized. However, there are countries –including theUnited States – with a far more decentralized healthcare system, in which a multitude of public andprivate organizations are providing and administering COVID-19 tests and vaccinations, and where each,hypothetically, could issue proof of an individual’s health status.
Additionally, there is wide variation in the existing digital infrastructure within healthcare systems, withvariability both between and within countries. In some jurisdictions, health care records are maintainedlargely in paper formats, with little individual-level data captured electronically. Healthcare systems insome areas can rely on constant, high-speed internet access, while others must contend with intermittent
connectivity at the point of care.
Finally, despite recent advances in health systems’ interoperability, different countries – and healthproviders – are at different points in adopting standards-based approaches for exchanging data
electronically. The Health Level Seven International (HL7) Fast Healthcare Interoperability Resources(FHIR) standard, designed to enable health data to be quickly and efficiently exchanged within thehealthcare ecosystem, is growing in use, but adoption remains patchy. Moreover, FHIR is only for theexchange of data between regulated providers of healthcare services and was never designed for broadand diverse exchange for non-healthcare use cases.
Interoperability becomes significantly more complex when considering health data exchange outsideof the healthcare ecosystem. International travel presents one of the most complex of all possible use
cases for exchange of health data, requiring extensive collaboration across multiple sectors and countlessjurisdictions.

The Good Health Pass Interoperability Blueprint31.1.2 Complexity of International Travel and Health Data
International air travel is an inherently complicated process. It is highly regulated and, by definition,
involves at least two governments who each require detailed information on who is intending to crosstheir borders. In addition, there are many stakeholders in the process, operating under more rules andregulations. Indeed, according to unpublished research from SITA, a multinational IT company thatprovides services to the air transport industry, as many as 23 different companies can be involved in theprocess of getting a passenger on board an aircraft and allowing it to take off.
The international travel industry has spent years ensuring underlying systems and processes areinteroperable, constantly available and globally standardized. In addition, technology providers haveworked to give the travellers a seamless journey experience, minimizing the interventions required.
However, these systems have largely broken down under the strain of new and shifting requirements for
COVID-19 testing and vaccination. Historically, airlines and other providers of international travel have
had to implement rules relating to immigration, which change, at most, a few times per year. In the midstof the pandemic, rules of entry are changing at short notice – sometimes on a daily basis – creating
uncertainty for travellers, airlines and scheme providers alike.
Moreover, while the industry has existing digital infrastructure used to automate these processes, the lackof integration of health status information with existing passenger processing systems has necessitatedmanual checks of travelers’ paperwork, causing delays and straining businesses. Many airports currently
require 100% of their pre-pandemic staffing levels to process just 10-15% of traveller numbers, while
immigration processes are commonly causing 5 to 6 hour delays.
And the travel industry is anticipating the situation becoming more complicated still, as multiple
incompatible systems are rolled out relating to COVID-19 health status. The pent-up demand for travel
could create an environment in which check-in agents, ground handlers, airport staff, immigration
and border control officers are faced with thousands of travellers from all corners of the globe with nostandard health pass formats, shifting rules of entry, little means to prove the authenticity of healthcredentials, and (in some cases) no access to the internet to carry out verification checks. At best, theresult could be unhappy passengers; at worst, a bending of the rules with the potential for disastrous
health consequences.
While outside of the scope of the GHPC, when considering use cases beyond proof of COVID-19 status forthe purposes of international travel, the world of potential issuers and verifiers becomes nearly infinite. It
is for this reason that open and interoperable standards are not only key to the current effort, but also to
set the standard for future consumer protections.

The Good Health Pass Interoperability Blueprint

4

2

The Good Health Pass Interoperability
Blueprint

2.1 Our Approach To A Good Health Pass
If the exchange of health status is to become a requirement for reopening our economies and borders,then members of the GHPC believe it is our responsibility to ensure that the technical ecosystem works
for everyone: individuals, organizations, and governments.
This means ensuring that:z The exchange of data is a private exchange between the individual presenting the data (holder) andthe organization receiving it (verifier), and cannot be tracked by a third party (which includes theoriginal issuer or verifier);z It minimizes the amount of data that the holder needs to exchange for the specific businessprocess; andz There is complete transparency between holder and verifier in terms of how the data will be used.
Technical interoperability also requires the creation of an interoperable trust architecture.
We believe a health pass (and the even more specialized version used for international travel, often calleda travel pass), as described below, offers a number of benefits over alternative models being discussed
for COVID-19 recovery:
1. Is difficult to falsify because it is digitally signed by a trusted entity.
2. Is less prone to loss, and easier to recover.
3. Minimizes the personal or health-related data that needs to be exchanged for a determination ofadmissibility (e.g., for a border crossing or international plane flight) or other business transaction.
4. Gives individuals control over their own data, including the ability to choose what information toshare and with whom.
5. Can be automatically verified when presented, without the issuer (or anyone else) knowing where it
has been used.
Here, terminology matters. Almost a dozen different terms have been used publicly to describe thecontainer of data a traveller needs to prove their COVID-19 health status. Most importantly the conceptof a Good Health Pass is NOT a “vaccine passport”, a widely misused term for our proposed architecture.
Of these terms, we settled on four to use precisely and consistently in the Good Health Pass architecture,across either paper or digital versions.
z Attestation:A set of claims about a subject for which the attester can be held accountable. This
includes a self-attestation.
z Certificate: A set of claims about a subject by an issuer that can be verified in some manner, either
manually or automatically.
z Credential: a certificate issued in a form designed to be easily transported by the holder and easily
verified by a verifier, especially using machine-readable data and/or cryptographic signatures.
z Pass:a credential to which data minimization and anti-correlation have been applied and any
relevant travel data has been added, so it includes only what a verifier needs to make a trust
decision in a specific context (such as boarding a plane).

The Good Health Pass Interoperability Blueprint

5

Figure 2: Good Health Pass Terminology
The key point of differentiation between a credential and a pass is that a pass encapsulates a businessdecision and only contains the data required to make that decision, such as “good to fly” or “good toreturn to work”, filtering out all other unnecessary and sensitive personal health information.
For a health pass to be “good,” it must obey the principles of lawfulness and purpose limitation, andapply data minimization and anti-correlation wherever possible, transmitting only the data the verifier
absolutely needs to know. In many cases, the only information that should be provided to the verifier(such as an event venue) is that the individual is deemed “safe”, based on the established requirements(e.g., vaccination, test status, etc.). This level of data minimization and privacy preservation is consistent
with the European Union’s General Data Protection Regulation (GDPR). It is critical for a global ecosystemwith multiple providers of health status (vaccination status, testing status, immunity status) within andacross jurisdictions (province, state, country, region), and with multiple organizations and governments
implementing for the disparate, and changing, policy requirements.

2.2 Key Design Choices
The foundational principles of the Good Health Pass Collaborative lead to a number of key design
considerations and technical choices. With these in mind, our analysis and recommendations are basedon five key pillars, as set out below.

2.2.1

The individual must be at the center of the dataexchangez Individuals SHOULD control their own data: what they share, with whom, when, and for what
purpose.
z Exchange of data SHOULD be private, between issuer/holder and holder/verifier, without third
parties able to track it.
z There MUST be transparency over how the data is processed, used or shared, with collection andmanagement of consent as required. Verifiers will be able to process data only, not to share it
onwards, unless they get explicit consent to share the data with a specific entity.
z We have chosen to adopt a decentralized identity architecture, incorporating the World Wide
Web Consortium (W3C) Verifiable Credentials Standard, to help enforce implementation of theseprinciples, where:| Verifiable Credentials (VCs) can be used to create a digital version of any paper credential,
such as a passport, driving license, health insurance card, employee ID, etc.

The Good Health Pass Interoperability Blueprint6

| Once an issuing organization releases data, as a VC, to an individual, then they have fullcontrol to share with whomever they choose, and the receiving organization can trust the data
without needing to go back to the original issuer.
| The VCs are digitally signed by the issuer. This means that the verifier (i.e., the party whoneeds to see proof of the credential) can verify the cryptographic signature to ensure that it
could only have come from the issuer and that it has not been tampered with. In other words,
they know it is genuine.
| When they present their data to a verifying organization, this is a private transaction in which
the verifier doesn’t need to interact with the issuer in order to check the validity of the data.
This peer-to-peer transaction model, combined with data minimization and other privacypreserving techniques, makes data exchange highly privacy preserving and reduces theopportunity for an individual’s data activity to be tracked.
z Given the requirement that a Good Health Pass MUST transmit only the data the verifier absolutely
needs to know, use of credential formats, signatures and exchange protocols that support selective
disclosure is vital. This will allow individuals to generate dynamic passes, on demand and in
response to the specific requirements of the verifier’s business process, such as passing throughborder security.
| We believe there is an important consumer education effort required to help individuals assert
their agency about what information to share – or not share – with potential verifiers.
| Without clear guidance on selective disclosure scenarios – the amount of information averifier of a particular type (i.e. a hotel) can request of an individual – reliance on multiple,
static passes creates friction for individuals and requires them to remember which pass touse in each setting. This could lead to regular use of the full “signed clinical health” data as ahealth pass, which shares a lot more information than is required for the particular use case.

2.2.2

Equity and inclusion are essential

z Until COVID-19 vaccines are universally available, health passes MUST allow someone to show
proof of COVID-19 health status (e.g. proof of a recent negative test result) as a condition ofentry, when required.
z Any system that restricts access to rights, privileges, activities, or venues exclusively to those able
– and willing – to present proof of vaccination poses significant equity concerns. Fully addressing
equity and inclusion concerns requires specifying and restricting the appropriate uses for a system.
The GDPR defines purpose limitation as a requirement that personal data be collected for specified,
explicit, and legitimate purposes, and not be processed further in a manner incompatible with those
purposes (Article 5(1)(b), GDPR). We call upon policymakers and regulators to specify appropriate
uses for a GHP system and agree, as a Collaborative, to abide by the purpose limitations set by all
relevant jurisdictions.
z Using the term “vaccine passports” in a generic sense is both technically imprecise and politicallyinflammatory; instead, we suggest use of the term “digital health pass”.
z Any digital health pass solution MUST work across the world without the requirement to possessa smartphone. Good Health Pass solutions MUST offer a hard copy alternative for those who do not
own – or wish to use – a smartphone.
z In recognition that a Good Health Pass solution will take time to implement end-to-end, theblueprint needs to be pragmatic and allow for incremental adoption and coexistence with existing
systems.

The Good Health Pass Interoperability Blueprint72.2.3

A decentralized approach is necessary for global
security and scalability

In our post-pandemic world, the widespread requirement of COVID-19 health credentials and passes
for international travel means that the exchange of health data will no longer be constrained to a small
number of regulated healthcare service providers. And as the world becomes ever more data-driven, thenumber of data issuers, holders, and verifiers across different jurisdictions and business processes willcontinue to grow. The traditional centralised or federated approaches are no longer fit-for-purpose. New
approaches are needed that allow the exchange of data in a way that is trusted, privacy-preserving,secure, scalable and controlled by the individual. The blueprint provides guidance on how to set up
decentralized yet interconnected governance frameworks and trust registries for governments andindustry coalitions that can support the issuance of trusted health credentials and passes.
A decentralized approach:z Empowers individuals to manage their own data, so they have it when they need it and can
exchange it through a secure, private, and verifiable channel.
z Allows any organization that can be proven to be trusted, through a global ecosystem ofdecentralized trust registries, to issue data to an individual and have that data trusted whenpresented to a verifier. We have elected to use the W3C Decentralized Identifier Standard as adecentralized approach to public key infrastructure.
z Moves data exchange to the person, where data is exchanged directly from person (device or
paper) to verifier, giving significant security and performance benefits; firstly, this moves awayfrom over-reliance on centralized repositories, reducing the risk of data breaches, and secondly
it significantly reduces traffic between healthcare information systems and (a potentially huge
number of) verifiers, each which could be a source of data breach.
z Reduces the ability for issuing organizations to track an individual’s data activity. As the dataexchange is peer-to-peer in nature, there is no requirement for the verifier to notify the issuer that atransaction occurs (which happens when they need to ping the issuer to verify).

2.2.4

Open standards are key to interoperability andparticipationz For global interoperability, we have chosen to focus on adoption of open standards, such as the
W3C Verifiable Credentials. Several GHPC members are also contributing to open source projects
so that good practice, techniques and capabilities can be shared across the community, helping
to drive interoperability and extensibility across use cases and geographies, and to increase
participation.

2.2.5

We must be pragmatic and realisticz The roll-out and adoption of a Good Health Pass is going to be a huge challenge that intersects withgovernment policy, business process, legal regulation, technical systems, and societal norms.
z Accepting that technical implementation always takes time, any proposal MUST be pragmatic andbe capable of being phased. The work of the GHPC will take a very practical approach, recognizingthat we need to move fast, but NOT break things. We will need to work within existing constraints,
making incremental improvements over the coming months and years to get us closer to our visionof a privacy-protecting, user-controlled, globally interoperable, and universally accepted digital
health pass system.

The Good Health Pass Interoperability Blueprint8z The approach adopted therefore enables downstream entities in the process (such as healthpasses) to act as verifiers of upstream data, where that health data cannot be fully verified atsource, in order that the benefits of the decentralised system can be achieved rapidly within
30-90 days.

The Good Health Pass Interoperability Blueprint93

Where Does the Blueprint Fit Within
the Industry?

3.1 Good Health Pass Ecosystem
In this race to meet the needs of the market it is unlikely that a single solution will be implemented
universally – or even across the entire travel industry. Instead, we expect – and fervently hope – that avariety of solutions will offer choices, both for the public as well as for implementers (e.g., governments,
airlines, employers, educational institutions, venues, etc.). Choice benefits users, who can select asolution that feels intuitive to them, and promotes inclusivity, as no single solution will ever be universally
appropriate. However, with choice comes interoperability challenges, as well as the potential for confusion
and lowered standards. For this reason, global collaboration and standardization is essential.
Enter the Good Health Pass Ecosystem.
The Good Health Pass Ecosystem aims to bring together standards bodies, technology providers,
government, policy makers, consumer advocates, and other stakeholders in the implementation of good
health credentials and passes within a global digital trust ecosystem, consisting of four core parties:
1. Issuersof credentials and passes (i.e. labs, public health systems, rules engines)
2. Holdersof credentials and passes (i.e. travelers)
3. Verifiersof credentials and passes (i.e. airlines, border authorities)
4. Governing Authoritieswho publish rules and policies in a governance framework (aka trust
framework)
The figure below shows the relationships between these four parties in a configuration sometimes
referred to as the “trust diamond”.

Figure 3: The Good Health Pass Ecosystem
The term “digital trust ecosystem” means that all credentials are in a digital format; however, it does
not mean that they are always stored or exchanged digitally, and in some cases paper MAY be used as
the medium for storage and exchange. This is suboptimal from a privacy or security standpoint, but is arequirement for those who do not have access to a digital device, or do not want to use one.

The Good Health Pass Interoperability Blueprint

10Given its breadth and scale, the Good Health Pass digital trust ecosystem MUST also support any
number of solution providers who compete to offer solutions that meet the needs of participants, while
adhering to the interoperability requirements the GHPC is developing.

3.2 Integration With Open Standards
While an open market has a number of benefits, it does create a need for these solutions to be designed
for interoperability – both with one another and across institutional and geographic borders. Technicaland organizational interoperability can only be achieved through the creation of a common set of open
standards to which all digital health pass systems must adhere, including standards for national lab andvaccinator accreditation, and identity binding and authentication. There are multiple standards efforts
underway across the globe, many of which will be adopted by different jurisdictions, companies, andtechnology providers.
The Good Health Pass Collaborative was created with the express purpose of bringing together disparate
geographic and vertical market efforts for health pass standards. From its inception, GHPC establishedaffiliations with a number of groups across the industry for both dialogue and support. More than 120
organizations have endorsed GHPC – these organizations are listed on the GHPC website.
In addition, GHPC formed partnerships with the COVID-19 Credentials Initiative and the Trust over IP
Foundation – both Linux Foundation projects – to address specification details.
z Trust over IP Foundation (ToIP): ToIP is defining a complete architecture for Internet-scale digitaltrust that combines cryptographic trust at the machine layer and human trust at the business, legal
and social layers. The trust framework constructed for the Good Health Pass Blueprint has beendeveloped in partnership with the ToIP Foundation.
z COVID-19 Credentials Initiative (CCI): CCI has been working with initiatives around the world toleverage verifiable credentials for COVID-19 use-cases and, since it joined Linux Foundation Public
Health in December 2020, has been working with public health departments globally to understandtheir needs. CCI published a key paper about the flavors of verifiable credentials in February
2021 and has been an active contributor to GHPC, specifically driving the verifiable credential
standardization and interoperability.
GHPC continues to engage with other emergent credentialing ecosystems and emergent specifications,such as:z Digital COVID Certificates – European Union (EU): This is a pan-EU initiative for member
states to align on an approach for the issuance of cryptographically-signed credentials in a Quick
Response (QR) code format, and is based on a custom data model. GHPC has already developed
mapping definitions between the EU Digital Covid Certificate and GHPC (See Section 6.1), alongwith other mappings such as FHIR to help make global interoperability a reality.
z Digital Documentation of COVID-19 Certificates (DDCC) – World Health Organization (WHO):
In March 2021, the WHO Smart Vaccination Certificate working group published Interim Guidance
for Developing a Smart Vaccination Certificate. The scope of the working group has since evolved
to include digital documentation of both COVID-19 testing and recovery alongside vaccination,
prompting the renaming of the specification to DDCC. At writing, the WHO has announced that
DDCC guidance will not include details of a technical architecture for a Global Health Trust
Framework.
z Vaccination Credential Initiative (VCI) – United States: This consortia is developing a technicalspecification, the SMART Health Card Framework, for the issuance of cryptographically-signed
credentials in QR code form. The SMART Health Card Framework uses the W3C Verifiable
Credentials JWT data model, which does not support selective disclosure. To enable users withgreater discretion of what data they share, we have outlined a simple process for a user to

The Good Health Pass Interoperability Blueprint11

“transform” a health credential issued using the SMART Health Card specification into a Good
Health Pass that natively supports selective disclosure. (see Section 6.2 Recommendation #5 forfurther detail)z Digital Infrastructure for Vaccination Open Credentialing (DIVOC) – India: This is opensource software and associated specifications developed within the India community, intended toaddress an approach to digitally orchestrate data exchange for vaccination data. This is specificallyaddressing the issuance of cryptographically-signed credentials in QR code form and is basedon the JSON-LD W3C Verifiable Credentials data model. See the DIVOC website here for APIs,
specifications, and backgrounders.
z Collaborative Arrangement for the Prevention and Management of Public Health Events in
Civil Aviation (CAPSCA): This is a cross-sectoral program managed by the International Civil
Aviation Organization (ICAO) and supported by WHO. It is a multi-stakeholder effort to develop
a global framework for COVID-19 test credentials, including standardization of documentation,interoperability of systems and exchange of data.
z International Civil Aviation Organization (ICAO): Technical Report VDS-NC Visible Digital Seal for
non-constrained environments. Version 1.0, 23 April 2021. ISO/IEC JTC1 SC17 WG3/TF5 for ICAO.
See more details here.
z Airports Council International (ACI): Airport Health Testing and Travel Information Standard, API
V1.0, 23 February 2021. See more details here.
z CARIN Alliance: Digital Identity and Federation in Health Care, December 2020. See White Paper
Reference here.
A failure to address interoperability – both from a technical and a trust perspective – will undermine
acceptance, adoption and, ultimately, the expected public health and economic benefits of digital healthpass systems. Each of these concurrent efforts is producing valuable work and bringing important
perspectives to the table. However, in order to avoid fragmentation and ensure that digital health passes
adequately meet the needs of travelers, airlines, and governments alike, urgent collaboration is needed toharmonize these standards.
The Good Health Pass Collaborative was established to weave together the work coming out ofthese various efforts and facilitate the alignment necessary for the resulting standard to be appliedinternationally across vaccination, test, and recovery status.

3.3 Building A Community Consensus
Bringing the vision of the Good Health Pass Interoperability Blueprint to life will require building acommunity committed to adopting these recommendations and creating GHP-compliant solutions. It will
also require forming a governing authority for an overarching ecosystem governance framework, whose
job is to:
1. Complete and approve the official first version of the governance framework.
2. Publish and maintain a dedicated website hosting the official governance framework documents.
3. Gather feedback and develop future versions based on the “in-the-field” experience of implementing
V1, as well as changes in other external factors such as regulations and health authority guidelines.
In keeping with the principles of good governance, we recommend that the GHP governing authority beformed and governed by the primary stakeholders in the GHP digital trust ecosystem.

The Good Health Pass Interoperability Blueprint

12

4

Solving for Interoperability: An Overview
of the Blueprint

To realize the vision of a globally interoperable ecosystem issuing, holding, and verifying Good HealthPasses, interoperability must be addressed at a number of levels.
Solutions must interoperate with one another technically; they must use common data models andelements, as well as standard credential formats, signatures and exchange protocols. This requires
gaining agreement on the VC formats, signature types, and exchange protocols, mechanisms for binding
the identity of the holder, and agreement on the QR codes to be used to present a digital health pass.
But, as important as technical interoperability, health pass solutions must offer a consistent user
experience. They must also be governed under a holistic governance framework. Trust registries arenecessary for accrediting the COVID-19 testing labs and vaccinators who will “issue” the credentials, aswell as those verifying them (relying parties).
The GHPC enumerated nine categories of interoperability challenges that must be addressed in order toachieve functional interoperability of digital health credentials and passes across borders and institutions.
In March 2021, members of GHPC joined together with members of ToIP in collaboration with the Covid-19
Credentials Initiative hosted at Linux Foundation Public Health to establish the Interoperability Working
Group for Good Health Pass (IWG for GHP). Hosted at ToIP, the IWG for GHP set out to expand upon
those nine categories of challenges and develop a cohesive set of recommendations, standards andspecifications that will allow a Good Health Pass Ecosystem to flourish. The following blueprint is a direct
deliverable of the IWG for GHP.
In many of the following sections, the recommendations are organized into “30 Day”, “90 Day”, and “180Day” horizon activities. This is intended to provide guidance on immediate steps that can be taken to
improve the current state of interoperability, as well as intermediary steps and future-looking steps
that can help us move toward full end-to-end interoperability. The table below summarizes the key
recommendations from each interoperability challenge.

Overall Recommendations
Consistent User Experience
The need to create a consistentuser experience, based on a modelof universal acceptance, is themost fundamental interoperability
challenge, where a Good Health Pass
MUST be easy to obtain, use, andupdate, without any special user
knowledge.

The Good Health Pass model encompasses three “zones” of apassenger’s journey and which create the foundation for a gooduser experience.
z These three zones are preceded by a person discovering the
COVID-19 requirements of a given travel itinerary.
z The zones (1 - 3) define the process by which a person:| Zone 1: Obtains a COVID-19 Test or Vaccination that meetsthe requirements.
| Zone 2: Obtains the COVID-19 Credential.
| Zone 3: Presents their COVID-19 Credential.

The Good Health Pass Interoperability Blueprint

13

Security, Privacy, and Data Protection
Good Health Passes MUST meetbaseline security and privacy
requirements that enable holders
to maintain full control of theirpersonal data.

z A Good Health Pass solution MUST comply with globallyrecognized privacy and data protection principles,
namely lawfulness, consent, data minimization, retention
requirements for data and technology, assurance of data
quality, information security, purpose specification and use
limitation, transparency, personal control and privacy rights,
and auditability and accountability.
z The drafting group makes detailed recommendations forwhat is required to meet each of the above principles.

Identity Binding
Good Health Pass compliant
implementations MUST apply
standard methods for verifying theidentity of the holder at specified
levels of assurancez Describes the role of identity binding in Zones 1 - 3.
z Solutions SHOULD record the levels of identity assurance,
working with existing systems to satisfy identity binding andauthentication recommendations.
z Identity binding MUST support low or no technology
solutions, providing verifiers with information on theidentity binding that has taken place so that the verifier can
supplement, as required.
z MUST follow globally accepted guidance for the levels ofidentity assurance driven by ISO/IEC 29115, chosen as themost internationally inclusive standard.

Credential Recommendations
Standard Data Models and Elements
Good Health Pass compliant
implementations MUST comprise astandard set of data elementsz There SHOULD be vaccination, test, and recovery passes,
in line with European Digital COVID Certificate minimal data
elements.
z Interoperability will require semantic alignment andharmonization with the recommendation to adopt theOverlays Capture Architecture (OCA).
z FHIR is the recommended data exchange format, specificallywhen integrating with healthcare systems.

The Good Health Pass Interoperability Blueprint

14

Credential Formats, Signatures, and Exchange Protocols
Good Health Pass compliant
implementations MUST use astandard set of credential formats,digital signature algorithms, andexchange protocols

z The recommended credential format is the W3C VC
standard, specifically the JSON-LD formatted VC with
BBS+LD-Signatures.
z When BBS+ is not possible, JSON-LD with Ed25519 digital
signatures is recommended.
z The recommended protocol is WACI PEx as defined by the
DIF Claims and Credentials WG.
z Issuers and verifiers MUST demonstrate adherence to all
jurisdictional security and privacy requirements, such as
ISO 2700X, ISO 29100, ENISA, GDPR, HIPAA, NIST CSF, or
Canadian ITSG-33.
z Performance requirements MUST be specified, included
against a variety of user devices to equity and cost
concerns.S
z upport paper-based solutions.
z Support offline credential exchange without Internet access.
z Accept non-W3C compliant credentials.

Offline Paper Credentials
An all-digital solution to healthpasses is unfortunately not an
option when it comes to combatinga public health crisis. Simple, easyto-use paper credentials MUST bean option so those in low-resource
settings or those who do not own –or wish to use – a mobile phone are
not excluded.

NOTE: Paper credentials can present risks to individual
privacy and are not the preferred approach for transmitting
personal health data. However, because there is a need toprove COVID-19 status without a smartphone or connectivity,
recommendations were developed to mitigate concerns as best
as possible:z Digital Credentials MUST be exchangeable as a QR code.
z All data MUST be encapsulated within the QR code for offline
exchange.
z The card SHOULD include both human readable text andmachine readable QR codes.
z It MUST provide data minimization.
z The card SHOULD include clear instructions for the holder ofthe credential.
z The size, format, and encoding of the QR code needs to meet
specific requirements so that it can be scanned and verified
by a variety of devices.

Operational Infrastructure Recommendations
Rules Engines
Good Health Pass compliant
implementations SHOULD havethe option to securely and privatelyinteract with any number ofrules engines from any numberof governance authorities toaccommodate variations in policy
and regulationsz Describes in detail the optimal rules engine subsystemdesign to address Good Health Pass requirements andinteroperability.
z Proposes separate subsystems for health and travel.
z Addresses passenger privacy, health status, and user
experience.

The Good Health Pass Interoperability Blueprint

15

Trust Registries
Good Health Pass compliant
implementations MUST be able toquickly and safely verify authorizedissuers and verifiersz A trust registry SHOULD be as basic as possible and notpush design constraints on implementers beyond the mostbasic requirements.
z It MUST be able to answer queries as to what issuers areauthorized to issue what credentials or passes, and also
what verifiers are authorized to request what credentials or
passes.
z Trust registries MUST support offline/no-network
environments with caching.
z Registry operators and data source providers MUST be
aggressively committed to sustaining trusted registrysources, encourage accountability and be committed torectifying problems that arise on an ongoing basis.

Governance and Trust Frameworks
An interoperable digital trust
infrastructure requires thatmembers agree on the business,legal, and social policies they
will follow to achieve their trust
objectives, with the collection ofpolicies, rules, and specifications
called a governance framework or
trust framework.

z The governance framework MUST take into accountexisting regulations, directives, and specifications forhealth credentials and health passes designed for proofof COVID-19 health status from governments and otherglobal authorities and industry consortia, including the EU
COVID-19 Certificate, the WHO Smart Vaccination Certificate,
the VCI SMART Health Card.
z It MUST follow all mandates specified in the ToIP governancemetamodel unless otherwise noted.
z It MUST incorporate all requirements specified in the Good
Health Pass Interoperability Blueprint V1.

4.1 Next Steps Beyond the Blueprint
The Blueprint is just the first step in bringing the Good Health Pass Collaborative’s vision to life. The
next phase will require us to empower the community with detailed specifications and reference
implementations and to help with adoption of the recommendations. We are already developing:z Technical specifications, or profiles, with clear conformance checklists against which implementers
can either a) test, or b) self-attest conformance.
z A simple self-certification program for publishing both: a) conformance reports produced by thetest suite (for anything that can be machine-tested), and b) self-attested conformance for any
requirement that cannot be machine-tested.
z Self-certification of ecosystem governance frameworks, which would be subject to human review.
Moving forward, GHPC will also continue to update the recommendations and technical specifications,as needed, and will build out a complete certification program to verify those who have self-attested
conformance. GHPC will also continue to advocate for these principles and standards, will work withstakeholders to support consumer and market education, and will generate data on the rate of adoptionof GHP-compliant health passes.
Finally, the work of GHPC has received significant interest from other travel-adjacent use cases. While therecommendations put forward in this document are intentionally limited to the international air travel use
case – and cannot be unilaterally applied to other use cases – we intend to work with these sectors andrelevant organizations to determine how best to adapt and revise recommendations for their use.
The Good Health Pass Interoperability Blueprint

16

5

Overall Recommendations

The Good Health Pass Interoperability Blueprint175.1 Recommendation #1: Consistent User Experience
5.1.1

Introduction

The Good Health Pass Collaborative was established, in part, to avoid a scenario in which people are facedwith confusing, conflicting, overlapping requirements for how they can prove their COVID-19 status. Suchfragmentation would not only make COVID health passes difficult to use, but would also impede adoption,erode confidence, and hinder equitable economic and societal rebuilding.
The need to create a consistent user experience – based on a model of universal acceptance – is the mostfundamental interoperability challenge we must meet. In short, a Good Health Pass (GHP) MUST be easy
to obtain, use, and update, without any special user knowledge.
A consistent user experience includes four key dimensions:z A consistent mental modelthat reflects a natural, intuitive process for using either paper or digitalcredentials. As with the introduction of mobile boarding passes over the last decade, the use ofverifiable credentials SHOULD be immediately adaptable to everyday processes and workflows,
such as booking a flight, boarding a plane, crossing a border, etc.
z Consistent terminology(semantic interoperability) such that required data elements arecollected accurately and user interface artifacts are presented consistently with meanings that areunderstood universally across all systems – the same way a red stop sign is universally recognized,
regardless of language.
z Consistent experience– just as driving a car requires unlocking the car, fastening the seat belt,
starting it, putting it in gear, and using the accelerator and brakes; we need to agree on generally
consistent experience for travelers, whether they are using a general-purpose digital wallet or a
special-purpose application. This includes setup, security and privacy warnings, consent and user
rights management, backup and recovery, and compatibility with paper credentials.
z Consistent governancethat is responsive to global, national, and regional regulations oroperational parameters (e.g, for when a test has expired, etc.) and is adaptable to change.

5.1.2

Background

While the COVID-19 pandemic has impacted every segment of the global economy, no sector has been hit
as hard as travel and tourism.
The travel industry has many stakeholders that work together to provide the services travelers expect. In
aviation, travelers of all budgets typically have access to a range of dining, entertainment and shopping
options. They have also grown used to the convenience of online services and mobile applications:
receiving digital visas in advance, and navigating airports predictably with the help of online check-ins andself-service options.
At the onset of the COVID-19 pandemic, all of this came to a halt. Many airports and terminals closed,with flights cancelled or switched to cargo-only. For travelers still flying, requirements remain unclear andprone to change, resulting in a lack of certainty on whether they are in compliance and long queues for
additional checks before departure and on arrival. Access to terminals is now restricted to “passengers
only”, and many of the self-service options have been disabled due to their inability to perform the everevolving requirement checks. All of these frictions further discourage travel.
Despite low passenger volumes, many travel stakeholders still have to maintain services and staff justbelow peak levels – a costly and inefficient situation that makes recovery a difficult prospect for theindustry at large.

The Good Health Pass Interoperability Blueprint18

5.1.3

Objective of this Drafting Group

It is unlikely that one single health pass solution provider will be applicable or appropriate for every use
case in every geography, even within the travel ecosystem. To that end, this group focused on articulating
the myriad of user journeys related to obtaining and using a health pass in the context of international
travel.
Given the multiple solutions that are coming to market, it is essential to outline functional interoperability
that can help airlines, airports, and consumers alike choose the best privacy-preserving products andreduce barriers to use. This includes ensuring that:
1. Owners of health certificates/credentials are able to present them as digital health passes andprove they were issued to them by accredited labs or health authorities and have not been tamperedwith.
2. Digital health passes can be interpreted and verified by a verifier regardless of what kind of healthcertificate they are based on or what kind of software was used to issue, store, or present them.
3. To offer consistent user experience, different digital wallet apps SHOULD follow a standard way ofreceiving, verifying, presenting, and integrating digital health passes.
4. Sharing of digital health passes SHOULD be consent based. Exchange of personal identifiable
information SHOULD be minimized or avoided.
5. The cost of system integration efforts required of stakeholders to implement the standard way ofreceiving, verifying and presenting digital health passes passed along to end-users (travelers)
MUST be low.
6. Health pass solutions SHOULD also be able to process paper health passes for users who do notuse mobile devices.

5.1.4

Understanding the User Journey

A good, intuitive user experience is built on a “journey map” that describes the sequence of events in a
typical usage scenario, such as purchasing a product on a website. The following is an overview of the user
journey for a health pass, as it relates to the example of international air travel. For the sake of discussion,“credentials” and “certificates” are used interchangeably. For this scope of this discussion, we will use theterm “certificate” to refer to any form of digitally-signed health credential, and the term “pass” to refer tosuch a credential when it contains only the minimum data required by a verifier.

5.1.4.1 Discovering COVID-19 Travel Requirements
Much like pre-pandemic planning, when a person decides to travel internationally, they create an itinerary,
decide where and when they wish to travel, and initiate travel arrangements.
Part of the planning is determining immigration rules for the country, countries, or regions to be visited
to verify what documentation is needed (e.g., visa, electronic declarations, and health information). Third
party aggregators, such as Timatic, ICTS ACI, and Sherpa, MAY aggregate and apply these rules – often
behind the scenes – so that travelers are prompted by carriers during the reservation process to ensurethat they will be in compliance during their travels. The rules MAY include:z “What are the entry requirements of my destination country(ies) and regions?”z “Where proof of a COVID-19 test or vaccination is required, what type of tests and vaccines are
accepted and from whom”
z “How long is this test or vaccination valid?”z “Will I need to get another test while I’m travelling?”

The Good Health Pass Interoperability Blueprint

19

z “What types of health passes are recognized by my destination country(ies), region(s), or air
carrier(s)?”z “How will my health information be used, shared, and protected?”z “Do I need to bring my passport for vaccination/testing?”
Now the traveler knows what is required of them and can seek out the appropriate tests, vaccinations,
and/or pass(es) as and when needed.
GHP envisions three “zones” to delineate the foundation of the user experience and applicable workflows,
as shown in Figure 4.

Figure 4: Identity binding and authentication zones in theGood Health Pass ecosystem

5.1.4.2 Zone 1: Obtaining a COVID-19 Test or Vaccination
A person completes a test from an authorized lab or provider (in person or at home), receives a
vaccination (in person), or provides documentation of COVID-19 recovery (e.g., antibody test or release
documentation, may also be at home or in person). They may ask:z “Can I get my test results in the time-bound window to fulfill travel requirements?”z “What proof of testing or vaccination does the lab or health facility provide? Is there a digital option,and can it be used internationally?”z “How far in advance do I need to receive a vaccine in order to ensure acceptable levels of immunity?
Is the vaccine I received recognized by or approved in my destination?”
In preparation for the COVID-19 test or vaccination appointment, and subsequently receiving a healthpass or credential, the person may need to install a relevant application (e.g., from an airline, government,or other third party) and create an account following local regulation and guidelines provided by the lab or
health facility.

5.1.4.3 Zone 2: Obtaining a COVID-19 Health Pass
A person obtains the necessary COVID-19 health pass(es) or credential(s) from the provider/issuer.
This MAY occur at the same time as receiving the service or at some subsequent time. This MUST also
allow for mitigation if the credential is issued in error or if the user disagrees with their health statusdetermination. They may ask:z “What certificates and in what format will be issued to me?”z “Why do I need a digital health pass when I have a health certificate?”z “Which health pass should I use for my travel purpose?”

The Good Health Pass Interoperability Blueprint20

z “How do I submit my certificates to my health pass?”z “How/who should be allowed to delete or amend the test and vaccination result (when an error
happened)?”z “What else do I need to do?” (i.e., health pass solutions are unlikely to cover all aspects ofinternational travel entry check, such as self-declaration, proof of hotel booking, proof of having
sufficient funds).
Prior to receiving the health pass or credential, the person MUST be prompted in advance to consent (ornot) to the collection and processing of required personal identity and medical data for the purpose of ahealth pass or credential in compliance with legal and privacy requirements.
The person’s identity will then be authenticated based on the existing identity binding protocols. This
MAY include creating a digital identity from physical ID (or record) or creating a digital identity by tying it
to existing digital credentials.

5.1.4.4 Zone 3: Presenting the COVID-19 Health Pass
At, or before, an authorized verification point(s), the user is requested to provide proof of one or more
COVID-19 health credentials or passes in a compatible format and they consent to provide such a proof.
The authorized verifier is able to verify that the COVID-19 health pass(es) are: (1) from an accredited lab
or vaccinator, authentic and unaltered, (2) sufficiently bound to the identity of the presenter, and (3)satisfy the verifier’s policy requirements.
The user should be able to perform the identification and verification digitally and remotely before
arriving at the airport in order to reduce the anxiety from not knowing whether they have complied withrequirements, to remove the manual checks that will inevitably cause queuing at check-in counter andimmigration, and to minimize infection through a touchless user journey.
Key questions:z “Can digital health passes enable users to submit and verify credentials and certificates before theevent (e.g., travel) so that only (digital) identity check is required on the day of the event?”z “Can users prepare and submit their entry declaration and contact tracing forms through digital
health passes?”

5.1.5

Discovering COVID-19 Travel Requirements

5.1.5.1 Problem Description
As the COVID-19 pandemic progresses, the complex and fast-moving array of health requirements
continue to vary by country and subnational jurisdictions. Without a standard set of requirements, thesecan be open to misinterpretation or even fraud.
In an ideal world, these requirements would be available in one place and accessible to all at every partof the journey. In reality, there are likely to be many sources (e.g. Timatic, ICTS ACI, Sherpa etc.) andtravelers often have to seek advice from other sources such as labs, airlines, and embassies – all of which
may present conflicting or slightly different requirements.

The Good Health Pass Interoperability Blueprint21

5.1.5.2 Good Health Pass Design Requirements & Considerations
In addition to providing the necessary information required for travel, a Good Health Pass could strive
to address user pain points, such as determining entry requirements based on destination input or
supporting search for a list of accredited, accepted, and supporting labs for test and vaccination, basedon destination input or test/vaccine type. This type of user interface will make it easier for travelers andpeople to interact and feel comfortable with health passes.

5.1.5.3 Recommendations
5.1.5.3.1

OVERALL RECOMMENDATIONS

One key step will be advocating for simple, clear international standards. The speed of changing
requirements will remain a challenge, but indications of which direction we are heading in will assist
decision-making. In light of these changing requirements, the Good Health Pass Collaborative makes thefollowing overall recommendation:
Travelers SHOULD follow the guidance from the International Civil Aviation Organization (ICAO) in ICAO
Doc 10152 5.2.2 Passenger journey through a PHC [Public Health Corridor] to take the following
actions pre-departure to ensure that their travel is as smooth as possible:
1. Confirm governments’ requirements (departure, transfer, and arrival) at time of booking and close
to departure.
2. Consult the airport / airline website and get acquainted to COVID-19 specific airport / airline
recommendations and instructions.
3. Obtain a COVID-19 health insurance policy (if necessary or recommended).
4. Book an appointment in a testing facility in time to comply with states’ requirements.
5. Present an identification document during the test and collect testing results.
6. Obtain authorized test result and upload to smartphone app and/or provide relevant information via
government portal (if applicable).
7. Ensure all traveling and entry requirements are fulfilled prior to departure to the airport.
8. Make sure to have a copy of the printed test result or the digital certificates or credentials available
to present at the airport.
9. Prepare travel kit (sufficient number of face masks for travel, hydro alcoholic gel less than 100ml,
etc.).
10.Do not travel if you are feeling unwell, have symptoms suggestive of COVID-19 or if you have been incontact with someone with COVID-19, and inform the air carrier in advance.
The following phased recommendations apply to countries, public health authorities, health pass
implementers, and international travelers who choose to follow Good Health Pass guidelines.

5.1.5.3.2

PHASE ONE (30 DAY HORIZON)

1. Countries SHOULD publish their health-related entry requirements in a fashion similar to how they
publish immigration entry requirements.
2. These health-related entry requirements SHOULD include what documentation (if any) is required
to be presented at the point of testing (or vaccination), how it is to be authenticated by the healthcare provider, and what elements are to be recorded in the corresponding health record which will
ultimately be required for entry into the destination country (or countries).

5.1.5.3.3 PHASE TWO (90 DAY HORIZON)Countries SHOULD publish their health-related entry requirements as described above in a standardized
way through digital channels (e.g., website).
The Good Health Pass Interoperability Blueprint22

5.1.5.3.4

PHASE THREE (180 DAY HORIZON)

1. Countries and subnational regions MUST make their health-related entry requirements publicly
available through digital channels, including a list of accredited labs or health providers, what data
is required, data format requirements, and any other relevant requirements so that international
travelers are able to use automated, digital means to determine what is required to visit a country(or countries).
2. Travel authorities:
2.1. SHOULD, in a similar fashion, enable international travelers to determine what is required toboard aircraft based on their route.
2.2. SHOULD not be required to process protected health information (PHI), especially as they
are likely not staffed to interpret test results
2.3. SHOULD, when possible, issue a GHP-compliant pass communicating a binary result (e.g.,“Fly”/“No Fly”) that is bound to the traveler’s identity (see Obtaining a COVID-19 HealthPass).
3. Health pass implementers SHOULD consider providing features based on the list of accredited and/or accepted labs and clinics to facilitate easier booking and referencing for the users.

5.1.6

Zone 1: Obtaining a COVID-19 Test or Vaccination

5.1.6.1 Problem Description
Having discovered the requirements that must be satisfied, a traveler will then need to seek out theappropriate health service, including taking a COVID-19 test with an approved provider within a given
timeframe.
Whether for travel or not, ensuring that individuals can continue to obtain COVID-19 tests or vaccinationsin the safest, most efficient, and most equitable way possible MUST remain a priority for the Good HealthPass ecosystem. However, this must also be with the understanding that the more processes of identity
proofing are relaxed, the more the risk of identity fraud grows. In general, this is why there have been
many approaches to defining and binding an individual’s identity – and/or resulting credential – to a test
or vaccination. Many healthcare providers, for example, have no formal identity verification and others
may rely on self-attestation to ensure inclusivity and increase operational efficiency.
Another issue is meeting common international legal and privacy requirements, namely the collection ofcompliant user consent at the appropriate points. These MUST be prior to data collection, and requested
each time prior to the data being processed or transferred. Whereas the practice of providing medical
information directly to an individual via printed or electronic copy does not require consent, it is standardpractice for health care providers to require consent before export of any health information to a third
party. Thus, if a health pass provider processes or receives medical information, it is recommended ahealth care institution obtain standard consent with appropriate archiving within the issuing institution.
This underscores the need to create user journeys for the creation of health passes that are consistentenough for an issuance process, but dynamic enough to minimize operational disruptions or barriers tohealth services. These journeys also differ substantially based on whether a person is seeking a test or
vaccination.

5.1.6.2 Good Health Pass Design Requirements & Considerations
When taking steps to meet travel requirements, travelers MAY obtain tests, vaccines, or other evidenceof health status in a variety of contexts – each of which MAY have their own informed consent process.
Any consent for the creation of a digital health credential or pass MUST be completed in addition to thisprocess.
The Good Health Pass Interoperability Blueprint23

5.1.6.3 Overall Recommendations
The steps to obtaining a traveler’s consent for sharing of health pass data MUST follow the consent
recommendations in the GHP Security, Privacy, and Data Protection Recommendations. As this isadditional to consent for a test or vaccine procedure itself, consent may best be considered in scope of
the issuance system the user interacts with.

5.1.7

Zone 2: Obtaining a COVID-19 Health Pass

5.1.7.1

Problem Description

Once a person has been vaccinated or tested, they will need to obtain a COVID-19 health credential orpass that will fulfill the requirements of the country(ies) or region(s) to be visited. Carriers may also needa version of the COVID-19 credential or pass (e.g., one without PHI, e.g., a “Fly” / “No Fly” indicator).
In either case, the healthcare provider will issue the credential(s) commensurate with applicableregulations which, for international travel, will likely include a means for the COVID-19 health pass to bebound to the identity of the individual that received the test or vaccination.
Because health credentials for the use of international travel will often be displayed to verifiers in varied
and often unfamiliar settings, the risk for inappropriate retention of medical information, even if it islimited in scope, presents a significant risk. For this reason, and regardless of the underlying architecture,
health pass systems need to provide an overview of potential risks and guidelines for use of the healthpass system. Acknowledgement of this information, along with the risks and benefits of system use,
will constitute consent for participation in a Good Health Pass framework. This description should be incommon language and targeted at a non-technical audience for both individual education and to aid thesocietal understanding of appropriate health pass expectations and usage.
There are two fundamental elements relevant to the validity of a COVID-19 health pass, (1) the
provenance of the health information and (2) the identity to which it is bound. Multiple user flows for
obtaining a COVID-19 health pass currently exist in reference to both identity binding and health record
authentication which have consequences for downstream interoperability of health credentials:
Identity verification protocols have many applications and an established framework describing
the level of assurance (LoA). The ISO/IEC 29115 Entity Authentication Assurance Framework
includes identity proofing (e.g., identity proofing, identity verification by passport agency), credential
management (e.g., credential binding and issuance by passport agency), and authentication (e.g.,authentication at point vaccination/test, at point of presenting health credential). The three zones
depicted in the diagram at the beginning of this document are authentication zones where theauthentication LoA is applicable.
The identity credential presented in each zone has an identity proofing LoA associated with it based on
the issuance process of the identity provider (e.g., passport agency). Four levels of LoA are:
1. Low:Little or no confidence in the asserted identity
2. Medium: Some confidence in the asserted identity
3. High:High confidence in the asserted identity
4. Very high:Very high confidence in the asserted identity

Please refer to “Recommendation #3 – Identity Binding” for more detail on this topic.

5.1.7.2

Good Health Pass Design Requirements & Considerations

Given both the recommended waiting period after COVID-19 vaccination and lower cadence (i.e., a traveler
MAY need to get tested before each trip, but only vaccinated once), it is more likely that health pass

The Good Health Pass Interoperability Blueprint24

issuance processes for vaccination, compared to testing, will take place after the point of care. As such,there may be varying levels of identity assurance, which – to ensure equitable access to vaccinations ingeneral – cannot be influenced by health pass providers.

5.1.7.3

Recommendations

5.1.7.3.1

OVERALL RECOMMENDATIONS

1. The Good Health Pass ecosystem MUST be capable of ingesting already-issued vaccine and test
certificates into the digital credential ecosystem. Good Health Pass issuance processes MUST
also fit existing health service and data exchange workflows for tests results and vaccinations. For
example:1.1. A copy of the test outcome (e.g., paper-based certificate) is uploaded into a travel wallet for
remote manual or automatic verification
1.2. A travel wallet app is downloaded in advance of a test. The results from the lab areautomatically populated into the application
1.3. Proof of vaccine status is made available to a person when it is required for travel
1.4. Detailed examples of user flows for obtaining health passes can be found in Appendix A:
Example User Flows for Obtaining a Health Pass.
2. The Good Health Pass ecosystem SHOULD enable an individual who has received a test and/or
vaccination to receive a credential (either digital, paper, or both) using a range of mechanisms,
including paper printouts, electronic health records (EHR), or via a QR code or secure web link, oranother appropriate form factor.
2.1. Depending on the timing and method of issuance of the credential, this step MAY require theindividual to re-authenticate to the issuer in order to assure that the credential is bound to theindividual’s identity.
2.2. In general, health passes SHOULD be able to be generated from multiple IDs, given thatdomestic travel and international air travel use cases have different identity assurance
requirements.
3. Issuers (be they health authorities or travel authorities) SHOULD ensure the subject’s identity isverified to the highest level of assurance supported by the issuer’s current accepted process.
4. Travelers SHOULD be able to run the entry rule check against their trip(s) before travel so that they
have opportunities to mitigate if something went wrong.
5. Travelers SHOULD be reminded to bring a copy of the test and/or vaccination certificate even if
digital verification is accepted.
6. Travelers SHOULD be warned that different digital identity mechanisms and authentication
requirements MAY be enforced at different points in their journey.

5.1.7.3.2

PHASE ONE (30 DAY HORIZON)The user experience will be impacted initially by the relevant government’s policy, especially for
vaccination certificates as this is normally written into country/state laws. The first dependency is thelegal ability to support a digital and/or paper issuance procedure; most are paper currently and somejurisdictions may require new legislation to enable digital equivalents or replacements. The following
recommendations address both practical and human rights issues.
1. Governing authorities, health authorities, and travel authorities SHOULD support issuance of healthcredentials and passes in both paper and digital formats and the corresponding user journeys.
2. The starting point SHOULD NOT disrupt existing processes.

The Good Health Pass Interoperability Blueprint25

3. Issuers SHOULD include a non-invasive method involving a minimum number of additional steps.
4. Issuers SHOULD where possible automate issuance using back-end electronic processes, forexample synchronising records from a hospital system, to a central immunisation database, which
automatically issues a credential provided specified conditions have been met. This effectively adds
only the initialisation of the traveler’s credential app, identity binding, and consent forms as user
experience requirements.
5. Where automation like this is not possible, issuers MAY assign dedicated issuance resources toprocess a large volume of records from health authorities in order to avoid placing more burden on
the health authorities themselves.
6. In countries or regions with low-tech health facilities and infrastructure (i.e. no or basic IT systems)
where automated approaches are not possible, health authorities MAY make simple software
capabilities available in smaller health centres in order to record health data and issue digitalcredentials at the point of testing or immunization. Note that this does provide a solution for
retrospective issuance – that requires an alternative approach.
7. In cases where there are only paper records and no central immunisation database – especiallywhen this involves large volumes of paper records – health authorities SHOULD employ a method
to digitise these records, such as scanning or photographing them with an app, in order to bringthem into the digital credential ecosystem.
| Such a system SHOULD employ automated verification to authenticate and validate thevaccination or test (including dates and type), as well as the identity binding of the subject.

5.1.7.3.3

PHASE THREE RECOMMENDATIONS (180 DAY HORIZON)Over time, the user flow MAY evolve into the following steps:
1. Traveler:
1.1. Downloads app
1.2. Registers appropriate information (including flight details, if not connected via API from airline
booking system)
1.3. Receives specific test requirements for trip (via API connection to TravelDocs or Timatic, etc.)
1.4. Links to booking platform for test centre / lab to schedule test
1.5. Goes to test centre
2. Health authority:
2.1. Uses verifier app and verifies identity document (in person, not remote)2.2. Performs test and pushes health credential or health pass to individual’s digital wallet app
3. Digital wallet app pushes health pass to (or is pulled by) departure control systems for clearance
to fly4. Individual
4.1. Stores their results on app
4.2. Has the ability to print a digitally signed health credential or health pass.

5.1.8		 Zone 3: Presenting and Verifying a COVID-19 Health Pass
5.1.8.1

PROBLEM DESCRIPTION

Travelers, especially internationally, will need to present different identity and health information todifferent entities, both public and private, during their travel journey. This MAY require selective disclosure
from one or more health credentials or passes to ensure compliance and to minimize the sharing ofhealth data.

The Good Health Pass Interoperability Blueprint

26

Each verifier MUST first validate the credential’s authenticity, integrity, and revocation status. After
validating the credential or pass, the verifier needs to determine if it meets their legal and/or business
requirements. Compliance rules are subject to temporal, legal, and business considerations.

5.1.8.2 Good Health Pass Design Requirements & Considerations
Interoperability of health credentials and health passes in zone 3 includes the following considerations.
1. Travelers SHOULD be able to present multiple credentials (e.g. vaccine + test; test 1 + test 2;
recovery + test).
1.1. T ravelers who are guardians of children or other dependents SHOULD be able to present
dependents’ credentials on their behalf. Unaccompanied minors or those in need of travelassistance SHOULD be able to present their credentials using existing processes in place.
2. All credentials SHOULD include adequate identity binding to support cross-border acceptance andimprove the overall user experience.
3. Travelers SHOULD be able to perform verification digitally and/or remotely before their journey
to reduce uncertainty and anxiety. Verification SHOULD include both non-stop and transiting
flights. Verification outcomes SHOULD be bound to an authenticated identity so that subsequentverifications can be simplified to identity verification only (unless otherwise prescribed by higher
assurance level verifiers, such as immigration / border authorities). Note that in this case, face-toface verification of health credentials or passes can be removed from the day of travel, and the user
journey is streamlined to reduce frictions and risk of infection.
4. Travelers SHOULD be able to minimize or completely avoid storing their personal data (e.g., identity,
medical, itinerary, booking, membership, etc.), to third-party systems other than the source systemand their decentralized digital wallet. When sharing is needed, it SHOULD be kept at a need-to-knowlevel and user consent SHOULD be obtained.
In the previous two zones, the focus was on ensuring healthcare institutions and travelers have easy
access to methods of creating and storing COVID-19 verifiable credentials. In this zone, the focus is on
creating a seamless experience for the traveler while at the same time enabling the verifier to verify thatthe traveler meets the applicable entry requirements.
In the case of international travel, what does the journey on the date of travel look like?

5.1.8.2.1

TRAVEL THROUGH THE AIRPORT ON DEPARTURE

Most checks on health requirements – paper or increasingly digital – are carried out primarily by theairline agent. Often, they will use the same sources used by travelers when planning their journeys.
However it can still take considerable time to navigate through these checks, especially for travelers withconnections where two or more rule sets must be checked.
Some health pass providers are providing apps for airline agents to speed this up. In addition, they may
use a rules engine to generate a “green tick” on a mobile boarding pass or other boarding document
to negate the need for the airline agent to perform this check. Passports are often used as the identity
check, with different levels of identity binding with health certificates depending on the source.
Ideally these checks are done prior to arrival at the airport as part of “at home check-in”. This also has thebenefits of:z Assuring travelers they have met the requirements prior to travelling to the airport;z Enabling travelers to use self-service machines, returning airport processing times back to prepandemic levels.

The Good Health Pass Interoperability Blueprint27

5.1.8.2.2 ARRIVAL AT DESTINATION BORDER-ENTRY
Upon arrival of the traveler, border control authorities in the arrival country or region MUST:z Verify immigration eligibility (where applicable)z Check health status and ensure that the COVID-19 credentials meet their entry requirements.
This usually duplicates the departure checks by airlines, but unfortunately there is no information flow
between airlines and border control authorities. As with the airport departure systems, many of theautomated machines for processing arrivals have not been put into place yet. However self-service isincreasingly being integrated into airline and airport processes, and in some cases this includes privacypreserving biometric verification.

5.1.8.3 Recommendations
For COVID-19 credential sharing and verification to contribute to the safe re-opening of international
travel, healthcare providers, technology intermediaries, airlines, airports, and border authorities need tocollaborate in an open, interoperable way to effectively protect public health and safety, while preserving
data privacy. If such an alliance comes to fruition, there is a meaningful opportunity to show the potential
of international, cross-industry cooperation to tackle this challenging global issue.

5.1.8.3.1

OVERALL RECOMMENDATIONS

1. Members of the Good Health Pass digital trust ecosystem SHOULD whenever possible focus on theissuance and verification of a health credential or pass prior to arrival at an airport by enabling backend system integration.
1.1. Whenever possible, this back-end system integration SHOULD verify the same healthcredential or pass as a native or independent verifier.
2. To meaningfully benefit global travel, credential presentation MUST be as lightweight, frictionless,and intuitive as possible.
3. Given the possible unreliability of airport connectivity (or wi-fi or connectivity anywhere while
traveling), the amount of data needed by the traveler to download their digital pass as well as
the amount of data needed by the verifier to validate that pass SHOULD be kept to a minimum.
Travelers SHOULD also keep a local copy of the credential or pass cached in case of intermittent
connectivity.
4. Verifiers MAY employ rules engines and/or decision support systems. There are two primary
options for credential verification and validation against a set of rules:
4.1. First-party rules enforcement: This applies when a credential is presented, verified, andvalidated according to the rules of a governance authority using a published governanceframework of some kind (including governmental legislation). For example:| A US-based hospital or clinic may provide a COVID-19 test and then issue a credential
based on requirements established by the Centers for Disease Control and Prevention(CDC).
| The US Transportation Security Administration (TSA) may then verify and validate thisCDC-governed credential at the point of departure.
4.2. Third-party rules enforcement: This applies when a credential is presented, verified andvalidated by a rules engine operated by a third party. Such a service MAY aggregate rules frommultiple governance frameworks.
| For example, a travel app MAY accept a travel itinerary as input, consult the rules engine,and return the COVID-19 test and/or vaccination requirements for that trip.

The Good Health Pass Interoperability Blueprint28

| Once a passenger has obtained the COVID-19 health pass(es) necessary to meet theserequirements, the rules engine MAY then issue a secondary credential – a travel pass –that the traveler can use for that journey.
5. Verification MAY occur natively (e.g., a digital health pass has an associated verifier that canauthenticate its own credential), or independently (e.g., a third-party verifier can authenticate
multiple different passes without issuing or holding a pass itself).
6. The recommend methods for requesting and presenting health passes are summarized in thefollowing table:

Sharing Credential Method

Verification Methods

Share QR code

QR codes MAY be produced on paper Read / scanned and verified by
or by a mobile device and presented to independent verifier, native verifier orverifying institution; QR codes MAY be human sight
uploaded in advance for either digitalor manual verification;QR Codes
MAY be scanned and ingested by anindependent verifier to get accepted or
to be combined with info (e.g. identity,
declaration) for entry check.

Near Field
Communication

MAY be used by a mobile wallet totransmit the credential to the verifier.

In-appApps MAY ingest a credential or passdesigned from a digital or physicalhealth record source (e.g., an airline
trip management app). With user
consent, ingested credentials or
passes MAY be passed to 3rd parties(e.g. verifier, rule engine, notary,
government) for relevant processing.

Manual verification

QR codes MAY be produced on paper Verified by sight from trusted digitalor by a mobile device and presented to health passes
verifying institution;

Integrated system

MAY perform pre-boarding verificationof health credentials or passes fortravel status verification prior toticketing or boarding pass issuance

Verifying institution needs acorresponding app to receive thecredential for verification
Verification is performed by checking
the ingested credential / passagainst a rules engine embedded
in-app5.1.8.3.2 PHASE ONE (30 DAY HORIZON)
1. Governing authorities, travel authorities, and health pass implementers MUST make a joint,concerted effort toward educating health authorities about the use of digital credentials and passes,
especially in the context of international travel during the COVID-19 pandemic.
2. In turn, governing authorities, travel authorities, and health pass implementers MUST work
closely with healthcare providers to ensure that proposed solutions are designed with publichealth objectives in mind and do not exacerbate underlying inequities in healthcare delivery. This
will pave the way for greater adoption of digital credentials needed to optimize the efficiency
and effectiveness of digital credentials for international travel – both for travelers and verifying
institutions (airlines, border authorities).

The Good Health Pass Interoperability Blueprint29

5.1.8.3.3 PHASE TWO (90 DAY HORIZON)
1. Members of the Good Health Pass digital trust ecosystem MUST undertake a collaborative effort toobtain feedback from health authorities, travel authorities, and verifiers about operational feasibility
and problem-solving.
2. Additionally, during this period, GHP-compliant ecosystems MUST improve the interoperability ofhealth pass solutions by continuing the development of standards and systems to build momentum
towards adoption.

5.1.8.3.4 PHASE THREE (180 DAY HORIZON)
1. Health pass implementers MUST consider solutions that will enable travelers and verifiers to returnas closely as possible to pre-COVID user experiences, including restoring online check-in, andshorter counter check-in times.
2. Health pass implementers SHOULD explore how Good Health Passes could be used for proof of
vaccination status in other travel-related use cases.

5.1.9

Additional Recommendations

The following are recommended requirements or features for future addendums.
1. Aggregating family or traveler companion passes, with a focus on guardianship and including
dependents or unaccompanied minors
2. Management of journey-specific health passes required by different jurisdictions (e.g., managing apass for the EU and a pass for Singapore as part of one journey)
3. Single vs. multiple health passes within a user wallet
4. Priority travel experience for holders of digitally verifiable credentials via airline, immigration, orverifying institution express lanes

The Good Health Pass Interoperability Blueprint30

5.2 Recommendation #2: Security, Privacy, andData Protection
5.2.1

Introduction to this Interoperability Challenge

All stakeholders in the Good Health Pass Collaborative (GHPC) digital trust ecosystem need to be
confident in the security and privacy of the ecosystem.
The GHPC seeks to put individuals in control of their personal data – including health attributes – which
they can selectively disclose for a specified purpose and duration. In order to achieve this aim, we havechosen to adopt a decentralized identity architecture which prioritizes privacy and personal data control.
Such systems stand in contrast to centralized models, which amass and store large amounts of personal
data that is under the primary control of the aggregator.
In some jurisdictions, these protections are already required by existing data protection regulations; inother cases, policy makers and regulators may seek to pass new legal and regulatory requirements toenshrine them in law.

5.2.2

Objective of this Drafting GroupThe objective of this Drafting Group is to provide Privacy by Design and Secure by Design
recommendations for Good Health Pass (GHP) solutions for international travel, and that are potentiallyextensible to other use contexts.
Privacy by Design places the individual at the center of the data exchange and takes into account privacy
and data protection across the ecosystem and throughout user journeys, from point of issuance to pointof verification. It includes all ethical, legal, operational, and technical considerations relevant to GHP
design choices and default settings (i.e. Privacy by Default).
Secure by Design comes hand in hand with Privacy by Design and is a key requirement for GHP solutions.
By “Security by Design” we mean an approach to information security which, like Privacy by Design, is atonce holistic, creative, anticipatory, interdisciplinary, robust, accountable and embedded into systems. It
stands in direct contrast to “security through obscurity,” which approaches security from the standpointsof secrecy, complexity or overall unintelligibility.
This Drafting Group also provides practical advice and direction to help bring these principles into theprocesses and architectures used in the creation of GHP-compliant credentials and passes. These willneed to be applied within the specific regulatory jurisdictions and contexts wherein those credentials andpasses will be used.

5.2.3

Problem #1: What legal frameworks apply?

5.2.3.1 Problem Description
There has been a proliferation of privacy, data protection and information security laws globally over thelast few years. Most notably, in the European Union (EU) the General Data Protection Regulation (GDPR)
2016/679, which has been in force since May 2018, triggered a trend for a number of countries andjurisdictions globally to reconsider their privacy and data protection legal frameworks. As a result of that,a number of new privacy laws of general applicability have emerged, such as the California Consumer
Privacy Act (CCPA) and the Lei Geral de Proteção de Dados Pessoais (LGPD) in Brazil. As of the end

The Good Health Pass Interoperability Blueprint31

of 2020, there were hundreds of bills that address privacy, cybersecurity and data breaches that werepending across the 50 states, territories and the District of Columbia in the US.
Besides data protection laws of general applicability, we also observe sectoral legislation aimed at
protecting individuals’ privacy, such as the Health Insurance Portability and Accountability Act (HIPAA),
along with other general legal frameworks with possible application to the collection and use of
vaccination-related data.
Interoperable GHP solutions may be challenged by the proliferation and complexity of existing andevolving privacy and data protection law.

5.2.3.2 Recommendations
GHP-compliant solutions for international travel MUST comply with the principle of lawfulness.
Lawfulness means that a legal basis exists for the processing of personal data in connection with theissuance of health credentials and passes, and for the purposes of collection and further processing ofdata related to vaccination, testing, credentialing and identity binding.
GHP-compliant solutions MAY be subject to one or more legal instrument which may be sector specific(e.g., a government law on health passes) or horizontal (e.g. the GDPR, the CCPA), depending on how
the data processing activities fall into their legal territorial (or extra-territorial) scope. GHP-compliant
solutions MUST comply with applicable law(s).
In some cases there may not exist specific laws regulating the use of health credential and pass solutions.
In such cases, GHP solutions MUST comply with generally applicable law.
While privacy and data protection laws vary and take into account unique legal, geographical, sectoral andcultural specificities, such laws generally embody certain common principles.
If there is no privacy and data protection law in a jurisdiction in which a GHP-compliant solution is
deployed, then that solution SHOULD take into account globally-recognised privacy and data protection
principles (such as GDPR), in order to ensure a minimum baseline for protecting individuals’ data privacy
and data protection.
GHP solutions SHOULD comply with the following globally-recognized privacy and data protection
principles:z Lawfulness
z Consentz Data minimizationz Retention requirements for data and technologyz Assurance of data quality
z Information securityz Purpose specification and use limitationz Transparency
z Personal control and privacy rights
z Auditability and Accountability

The Good Health Pass Interoperability Blueprint32

5.2.4

Problem #2: Consent

5.2.4.1 Problem Description
There is significant public, policy and regulatory debate on whether health credentials and passes should
be mandated for public health purposes.
Mandates for health credentials and passes may not only interfere with fundamental human rights, suchas equality and privacy, but may be inconsistent with data protection law.
Regardless of whether the issuance of health credentials and passes will be mandatory or not, there is arisk that processing of personal data in the context of health passes may take place without individuals’
consent. Therefore, user consent is needed for the creation of health credentials and passes.
In addition, to the extent health credentials are created on behalf of minors, appropriate parental consent
is similarly necessary.

5.2.4.2 Good Health Pass Design Requirements & Considerations
Primary considerations for this section include how consent manifests in the different zones, and theattributes of consent that would constitute “good” informed consent.

5.2.4.3 Recommendations
The processing of personal data in the context of GHP international travel solutions MUST have alegal basis.
For instance, under the GDPR, GHP-compliant solutions that process information relating to vaccinationor test status MUST satisfy the requirements of consent (Article 6 GDPR) and special category data
(Article 9 GDPR).
Valid consent means that the consent MUST be informed, specific, explicit and free.

Consent

Zone 1

Zone 2

Zone 3

Informed

Process MUST be put in place
to allow individuals to consent
to the issuance of a credential
with COVID-19 health status
information.

Process MUST be put in place to ensurethat individuals consent to how their data isprocessed, used, retained and shared in thecontext of issuing a credential and binding
it to an identity or for use in a health passunless applicable law provides alternative legal
grounds of processing personal data (e.g., theGDPR).

Specific

Individuals MUST consent
to issuing a credential with
COVID-19 health status
information specifically AND to
the use of their data by a specificentity or entities for that specificpurpose.

Consent MUST NOT be obtained in avague manner for a number of undefined
purposes. To the extent that Zones 2 and 3
involve biometric data for authentication
purposes, for instance for credentialing orbinding purposes, consent MUST be obtained
specifically, unless otherwise permitted byapplicable law

The Good Health Pass Interoperability Blueprint

33

Explicit

Individuals MUST take anaffirmative action to proceed
to vaccination or testing inconnection with the issuance of ahealth credential.

Consent to the processing of health data
MUST involve an affirmative action (forexample “do you wish to share this data?”).
Consent to the processing of biometric data
MUST involve an affirmative action, unlessotherwise permitted by applicable law.

Free

Free consent means that
individuals MUST be provided
with a number of valid
alternatives.

Individuals MUST be able to withdraw consent
at any point after consenting to the processingof their personal data.

These MAY be: vaccination,
testing or proof of recovery from
Covid-19. In Zone 1, free consent
MUST include a possibility towithdraw, (e.g., an individual
decided to withdraw from avaccination list).

Digital GHP solutions MUST provide an easily
accessible “withdraw consent” functionality inthe user experience.

5.2.4.4 Recommendationsz The issuance of GHP solutions MUST rely on individuals’ consent, or in the case of minors,
appropriate parental consent
z The processing of personal data in the context of GHP health credential and pass solutions MUST
rely on consent unless otherwise permitted by law.

5.2.5

Problem #3: Data minimization

5.2.5.1 Problem Description
Issuance and maintenance of health credentials and passes is an intrinsically data-driven activity thatinvolves the processing of sensitive personal health data.
It may involve the processing of biometric data (like matching a photograph) which is also consideredsensitive in several jurisdictions.
The development and deployment of health credential and pass solutions faces the risk of collecting or
storing more data than is strictly necessary.
Importantly, it is essential to apply the principle of selective disclosure of information and avoid
identifying individuals directly when identification is not required to verify health status.

5.2.5.2 Good Health Pass Design Requirements & Considerations
Data minimization plays an important role in terms of privacy, and there are several different techniquesthat can be used, often in conjunction with one another, to accomplish the goals of data minimization.
This section considers those different approaches.
GHP solutions MUST comply with the principle of data minimization. Data minimization means that
personal data processed, used, stored, and shared in health credential and pass solutions MUST belimited to what is absolutely necessary for a specific purpose (e.g., vaccination or testing, credentialing,
identity binding and authentication).

The Good Health Pass Interoperability Blueprint34

5.2.5.3 Recommendations
GHP solutions MUST comply with the principle of data minimization.
GHP data minimization design practices MUST be considered as part of the GHP solutions design
as follows:
1. GHP solutions MAY collect personal data and MUST store and/or retain the minimum amount of
personal data possible.
2. GHP solutions MUST rely on the storage of anonymized/de-identified data to the extent feasible.
3. GHP solutions MUST consider whether anonymized/de-identified data stored in their systems
still qualify as personal data and are subject to the requirements of applicable privacy and dataprotection law.
3.1. This will be the case when information which has been de-identified or anonymized can still belinked back to an individual.
3.2. In some jurisdictions (e.g., GDPR) the mere possibility to re-identify an individual when adding
or combining information between different entities, even if an entity has no such ability on its
own, renders the data personal.
4. GHP solutions MUST put appropriate measures in place to prevent re-identification when reidentification is not absolutely essential.

5.2.5.4 Identity binding and data minimization
While health credentials for international travel MAY contain more personal data (including personallyidentifiable information and protected health information) than GHP-compliant health passes, toimplement the appropriate level of data minimization the assurance level required by the context of a
specific use case MUST be considered. The following table explains the approach for GHP-compliant
health passes used in international travel:

Use case

Assurance Level

Data minimization

Boarding a plane or a
train

Need to bind an identity with atraveller

GHP-compliant health passes MUST
bind the traveller to the pass. The pass
SHOULD be a “Yes/No” or “Traffic Light”
factor indicating eligibility to board aplane or a train. Passes SHOULD NOTcollect or disseminate information about
the date and time of a COVID-19 test OR
the date, time and type of vaccine.

Crossing the borders

Need to be able to perform
legally required bordercontrol checks

GHP-compliant health passes MUST
bind the traveller to the credential.
The pass MUST contain the minimum
required information to perform legallyrequired border control checks. In
accordance with applicable law, it MAY
involve more information compared tothe case of boarding a plane or a train,
for example, date and time of taking a
COVID-19 test.

In use cases other than international travel, however, the principle of data minimization could be applied
to entirely avoid the binding of individual identity to health passes. For example, a health pass solution

The Good Health Pass Interoperability Blueprint

35

used in public entertainment venues could employ a “Yes/No” or “Traffic Light” system to validate anindividual’s eligibility to enter a particular venue, and by doing so preserve anonymity by avoiding the needto bind individual identity to the pass.

5.2.6

Problem #4: Purpose specification and data use
limitation (“Purpose Limitation”)

5.2.6.1 Problem Description
Data protection laws generally require that entities collect and use an individual’s personal data for the
specific purposes for which that information will be used. Function creep, which can occur when theprinciple of purpose specification and data use limitation is not respected, can give rise to significant risks(for example, unjustified surveillance).
GHP solutions that collect personal data in connection with international travel MUST clearly explain the
expected use purposes to the individual at the time the personal data is first collected and/or consented
to, and also document the fact of the entity’s disclosure of these purposes. Moreover, health credential
and pass solutions MUST obtain consent if they decide to use the individual’s personal data for a new
purpose not originally disclosed, unless the purpose is otherwise duplicative or allowed by applicable law.
Without a basis for using the data for a new purpose, the entity MUST use the data solely for the purposes
originally disclosed. Adherence by GHP solutions providers to the purpose specification and data use
limitation principle prevents “function creep”.
The requirements of purpose specification and data use limitation pose particular challenges for GHPcompliant solution providers: the operation of health passes necessarily implies not only the storage ofindividual health status information by credential issuers, but also downstream access by health passverifiers to some portion of that health status information (depending on the requirements of the context
in which the pass is presented).
Accordingly, responsibility for appropriate communication of data use SHOULD be shared across the“chain” of entities enabling the functionality of health passes; GHP health credential solutions MUST
ascertain that they have defined and clearly communicated the purposes of data collection intended tosupport downstream use by health pass verifiers.

5.2.6.2 Good Health Pass Design Requirements & Considerations
GHP solutions for international travel MAY collect and process personal data for specific purposes,
which include the validation of verifiable credentials and passes, as well as necessary system-level audit
processes. However, GHP solutions MUST NOT collect, share or sell such personal data for marketing or
advertising purposes.
In addition, GHP solutions MUST NOT use collected personal data for new and previously undisclosed
purposes without appropriate safeguards. Prior to enabling new internal or external personal data uses,
GHP solutions MUST perform a secondary purpose compatibility assessment, i.e. an assessment of
whether a new data use is compatible with the original purpose for which the data was collected.
Subject to applicable data protection law, safeguards to ensure purpose specification and data use
limitation MAY be the individual’s explicit and informed consent, the description of each purpose of data
usage in the privacy notice, and performing a secondary purposes compatibility assessment. Purposes ofuse of personal data MUST be clearly communicated to the individual.
In Zone 1, to the extent that a health organization is gathering data in connection with vaccination or
health status that is intended to be used for the creation of GHP health credentials, such an organization

The Good Health Pass Interoperability Blueprint

36

MUST comply with the purpose specification and data use limitation principle, either at the time ofdelivery of vaccination or health evaluation, or at such time as access to the health-related data for anindividual is first enabled for use in connection with a GHP solution.
In Zones 2 and 3, issuer and verifier solutions MUST comply with the principles of purpose specificationand data use limitation for the use of individual health data in a GHP solution, unless such use has beenpreviously disclosed or is compatible with prior disclosures.

5.2.6.3 Recommendations
1. To assist GHP solutions providers in ensuring that the principle of purpose specification isadequately addressed, model disclosures (or checklists of data purposes disclosures) MAY be
developed for GHP credential and pass solutions providers in Zone 1, Zone 2, and Zone 3.
2. GHP solutions providers in Zone 3 SHOULD also conduct reasonable diligence to ascertain that
where feasible, providers earlier in the “chain” of services necessary to support the issuance andverification of health passes for international travel have disclosed the expected purpose of uses ofindividual health status data for presentation to Zone 3 GHP solutions providers.
3. GHP solutions MUST perform a secondary purposes compatibility assessment before new internalor external data uses are allowed.
4. GHP solutions providers SHOULD limit disclosure of health-pass related data to public authorities tothe circumstances in which such disclosure is compelled by law or other appropriate legal process.

5.2.7

Problem #5: Retention requirements for data andtechnology

5.2.7.1

Problem Description

In addition to data minimization requirements, data protection laws generally prescribe that personal data
shall be retained only as long as necessary to fulfill the purposes for which it is collected.
This principle of limited retention applies to the storage of personal data collected in connection with GHP
solutions, and should be considered by any entity involved in the collection and use of such data in thecredentialing and presentation process.
In addition, certain jurisdictions in which health passes are used may implement specific retention
requirements tied to the type of health data stored within digital health pass technology. Just as agovernment may exercise the power to declare the onset – and conclusion – of a public healthemergency relating to a particular disease, a government may also choose to define the appropriate
retention of personal health data relating to that disease.
A government’s declaration that a public emergency has “ended” may affect not only the retention ofindividual data stored within health pass technologies, but may also affect the conditions on which
the technology underlying the health pass may continue to be lawfully maintained in that particularmarketplace.
At the same time, to the extent that individuals have a legitimate interest in maintaining information
relating to their prior health condition or vaccination as an element of their individual medical histories,
due consideration MUST be given to that individual interest in technologies used to support healthcredentials, to the extent consistent with applicable law.

The Good Health Pass Interoperability Blueprint37

5.2.7.2 Good Health Pass Design Requirements & Considerations
Personal data, including pseudonymous data, collected or used by GHPC entities in connection with GHP
solutions for international travel MUST NOT be retained longer than the maximum duration permitted
by governing data protection law in the relevant jurisdiction (including laws applicable to the retention of
public health data), and MUST be deleted in the event of any superseding determination by a competentauthority foreclosing the retention of specific categories of GHP-related data within certain technologies(such as a requirement for deletion of COVID-19-related health data following declaration of the end of thepandemic).

5.2.7.3 Recommendations
1. Providers of GHP solutions MUST comply with all relevant retention limitations for health status–
related data. Providers of GHP technologies SHOULD apply the general principle that retentionof individual data collected or used in connection with health passes will be limited to the strict
minimum necessary. Personal data MUST NOT be retained without a specifically defined purpose.
2. Providers of GHP technologies MAY consider the de-identification or anonymization of health passrelated data in their data retention strategy. It MAY be justifiable to retain de-identified data longer
than a full data set, whereas fully anonymous data in line with applicable law will not be subject tothe data retention principle (recognizing that the threshold for full anonymization of data is very
high in some jurisdictions and may only be met if it is impossible to link information back to anindividual with any reasonable means).
3. As part of their application of the principle of Privacy by Design, providers of GHP solutions
SHOULD design their technologies to anticipate the possibility that governments may impose
particular retention requirements for certain categories of disease or health condition data (to theextent that a decentralized data architecture does not independently address this requirement).
4. For providers in both Zones 2 and 3, retention of personal data related to the locations in whichthat individual presents a health pass MUST NOT be retained in the absence of a specific legal
requirement for such retention that is appropriately related to the use case in which it arises (forexample, retention requirements for international travel).
5. Providers of GHP solutions MUST publicly disclose their data retention policies.

5.2.8

Problem #6: Data Accuracy/Quality

5.2.8.1 Problem Description
A common principle across global data protection laws is data accuracy and quality. It is the notionthat personal data should be relevant to the purposes for which they are to be used, and, to the extent
necessary for those purposes, it should be accurate, complete and kept up-to-date.
Data quality clearly links to the right to rectification, which gives individuals the right to have inaccurate
personal data corrected.
Data quality is especially relevant for data-driven solutions such as health passes, as their value andefficiency derives from the quality and accuracy of the information they contain.
Another challenge that the principle of data accuracy and quality intends to address is that personal data
may be amended over time (for example, an individual may change their legal name after marriage).
Additionally, data may be lost, stolen, tampered or outdated.

The Good Health Pass Interoperability Blueprint38

5.2.8.2 Good Health Pass Design Requirements & Considerations
1. GHP solutions MUST take steps to keep personal data accurate and up-to-date and ensure that
personal data is not incorrect or misleading.
2. In Zone 1, the quality of data used in health credentials is a responsibility of the health organization
performing the vaccination or testing per their usual privacy and data protection practices. Robust
identity binding is key to ensure the accuracy of the personal data in Zones 2 and 3 for use ininternational travel.
3. GHP solutions MUST allow individuals to obtain, renew or update their credentials and passes freeof charge. The credential/pass, as well as its history of modifications, MUST be issued upon requestof the individual.

5.2.8.3 Recommendations
GHP solutions MUST comply with the principle of data quality and make sure that personal data is
accurate, complete and kept up-to-date.
Participants in the GHP ecosystem MUST take all reasonable steps to achieve this by allowing individuals
to update or issue new certificates in case their data is not accurate or out of date or the certificate is nolonger available to them (for example in case of loss, damage or theft).

5.2.9

Problem #7: Transparency

5.2.9.1 Problem Description
Health pass ecosystems are often characterized by complexity.
The number of actors, the sophistication of technology solutions as well as the type of governanceinvolved are not immediately obvious or intuitively understood by the majority of the traveling population
using health passes.
This creates a major transparency challenge about personal data collection and usage in all three GHP
zones, notably, at the stages of issuing, maintaining, binding identity, and authentication. This is also achallenge when actors in the ecosystem may be financially motivated to limit transparency or obfuscate
how they may be using health data in their systems.

5.2.9.2 Good Health Pass Design Requirements & Considerations
GHP solutions MUST take steps to explain how they process personal data in a clear and simple manner.
In connection with international travel, GHP solutions MUST clearly outline their processes and provide
individuals with information on the type of processing that is taking place and who is carrying it out.
At a minimum, this information MUST include:
1. Who is the entity processing the personal data
2. Who is the entity the user is agreeing to give access to their data
3. Why is the personal data processed including all relevant data usage purposes
4. If applicable, what legal basis an entity relies on to perform the data processing
5. Whether or not the personal data will be disclosed to other entities
6. How long the personal data will be stored
7. The existence of the individual’s rights, including in particular, the right to access, correction,
erasure, restriction, objection and portability to the extent applicable

The Good Health Pass Interoperability Blueprint39

8. The business model of the processing entity MUST be declared when joining the GHP Ecosystem
Governance Framework

5.2.9.3 Recommendations
In light of the requirements in the previous section, GHP solutions MUST take reasonable steps to provide
transparency in the clearest manner possible.
1. In Zone 1, the health organization performing the vaccination or testing in connection with healthcredentials MUST inform individuals in a clear and plain language of how their information will beprocessed by them.
2. In Zones 2 and 3, the issuer of the GHP solution as well as the verifier MUST also provide plain andclear information on how they process personal data.
Information about GHP solutions MUST be provided in layers or using visuals, in order to beunderstandable to different types of audiences and comply with applicable guidelines for accommodating
disabilities. In addition, information contained in GHP solution certificates MUST be shown in humanreadable form.

5.2.10Problem #8: Information Security

5.2.10.1		 Problem Description
Because GHP solutions for international travel will be dealing with personal data, including sensitive
health data, information security is extremely important not just in each of the zones, but also in theboundary crossings between zones.
Data needs to be protected both in transit and at rest.
While specific standards and regulations vary across the globe, to achieve Security by Design, it isexpected that actors in each zone are following local laws and regulations, and that information security
best practices are being applied.

5.2.10.2		 Good Health Pass Design Requirements & Considerations
The requirements and considerations will look at data and the different actors involved. In addition to
the issuer–holder–verifier trifecta, we’ll also look at organizations that either manually or automaticallyconvert certificates to passes external to the holder (“intermediaries” herein).
Paper-based credentials and passes have their own special considerations. The same security
requirements are in effect for issuers and verifiers regardless of the form of the issued credentials or
passes. For the holder-specific parts of these requirements, we will focus on the non-paper formats.
1. Data at rest
1.1. A ll credential and pass data, whether or not it is considered personal data, MUST be
encrypted at rest.
1.2. The security scheme protecting encrypted data MUST be separate from the security scheme
protecting its encryption keys.
1.3. Data at rest MUST be encrypted using strong encryption techniques as defined byjurisdiction-specific standard bodies.
2. Data in transit
2.1. Data transiting between zones, whether or not it is considered personal data, MUST utilize
end-to-end encryption.
2.2. Transiting data MAY have multiple encryption “wrappers” applied while in transit.

The Good Health Pass Interoperability Blueprint40

2.3. End-to-end encryption keys MUST be unique to the actors participating in the transmission.
2.4. Nonces SHOULD be included in the data transmission approach to avoid replay attacks.
3. Issuer-specific requirements and considerations
3.1. Medical issuers MUST have regulatory or other legitimate reasons for data retention.
3.2. Issuers SHOULD be aligned with relevant, well-accepted information security standards suchas ISO/IEC 2700x and 2910x.
3.3. Issuers MUST publicly disclose the information security and privacy standards and guidelinesthat they are following.
3.4. Issuers SHOULD publicly disclose their information security policies.
3.5. Issuers MUST publicly disclose their credential issuance policies.
3.6. GHP solution providers SHOULD ensure logging of events such that no personal data iscaptured or retained.
3.7. A ll system-level or debugging logs MUST be sanitized of any and all personal data to theextent feasible. If logs qualify as personal data under applicable law (e.g., under the GDPR),
GHP solutions MUST take steps to remove any personal data directly identifying individuals.
(e.g., sanitization).
3.8. Issuers MUST create and maintain an information security threat matrix, which SHOULD bereviewed quarterly.
3.9. Issuers MUST perform a Risk Assessment including an information security threat matrix
annually.
3.10. Issuers MUST perform internal and external security audits of their information
infrastructure.
4. Digital wallet app–specific requirements and considerations
4.1. Digital certificates and passes MUST be stored securely.
4.2. Digital certificates and passes MUST be accessible via multiple modalities (digitally, online,
offline or paper based).
4.3. Digital wallets MUST segregate users (e.g., parent and child) so that digital certificates andpasses cannot be intermingled.
4.4. Digital wallet apps SHOULD take advantage of “secure enclaves” when available on the device
to store cryptographic key material.
4.5. Solutions MUST provide a mechanism for the user to audit what data they have sharedwith whom.
4.6. All system-level or debugging logs MUST be sanitized of any and all personal data to theextent feasible. If logs qualify as personal data under applicable law (e.g., under the GDPR),
GHP solutions MUST take steps to remove any personal data directly identifying individuals.
4.7. Digital wallet app vendors SHOULD publicly disclose their information security policy.
4.8. Digital wallet app vendors MUST create and maintain an information security threat matrix,
which SHOULD be reviewed quarterly.
4.9. Digital wallet app vendors MUST perform internal and external security audits of theirinformation infrastructure.
5. Verifier-specific requirements and considerations

The Good Health Pass Interoperability Blueprint41

5.1. Verifiers MUST NOT possess the provided personal data for more than the minimum
timerequired to provide the granted benefit, unless otherwise required by law or regulation.1
5.2. Display of personal and sensitive health data during the verification process SHOULD
minimize the possibility of visual eavesdropping.
5.3. Verifiers SHOULD be certified under a relevant GHP-compliant scheme such as well-accepted
information security standards like ISO/IEC 2700x and 2910x.
5.4. Verifiers MUST publicly disclose the information security standards and guidelines that they
are following.
5.5. Verifiers SHOULD publicly disclose their information security policies.
5.6. All system-level and debugging logs MUST be sanitized of any and all personal data to theextent feasible. If logs qualify as personal data under applicable law (e.g., under the GDPR),
GHP solutions MUST take steps to remove any personal data directly identifying individuals.
5.7. Verifiers MUST allow holders to exercise the right to be forgotten.2
5.8. Verifiers MUST NOT share personal data, including sensitive health data gathered fromholders without the holders explicit, informed consent,. (See also consent section).
5.9. Verifiers MUST create and maintain an information security threat matrix, which SHOULD bereviewed quarterly.
5.10. Verifiers SHOULD perform internal and external security audits of their information
infrastructure.

5.2.11		 Problem #9: Personal Control and Privacy Rights
5.2.11.1

PROBLEM DESCRIPTION

Privacy is not about secrecy; it’s not about having something to hide. Privacy is all about control –personal control over the use and disclosure of one’s personal data. Only the individual knows the context
associated with the data involved – its sensitivity or lack thereof. Therefore the individual MUST be theone to determine the fate of his or her personal data; the individual MUST be able to exercise control overits use and disclosure.
Individual rights of control over one’s personal data encompass both control over the integrity of thatdata and control over the manner in which such data is accessed by others. With respect to the integrityof individual data embedded in health passes, GHP solutions providers MUST ensure data quality, and
MUST also address individual rights to access, correct and delete information.
In circumstances in which a GHP solutions provider cannot provide rights of access and correction
directly (for example, where a Zone 2 or Zone 3 solution provider receives information downstream fromthe original creator of a health data record in Zone 1), the solutions provider SHOULD provide access toan appropriate mechanism to request such correction from the original creator.
With respect to control over the sharing of individual data embedded in health passes, GHP solutions
providers’ adherence to the principle of Privacy By Design ensures that individuals benefit from a variety
of protections, ranging from de-centralized storage of their data to the ability to selectively disclose whatis shared with health pass verifiers. Rights of deletion, however, remain fundamental: each GHP credential
and pass solutions provider MUST allow for the deletion of personal health pass information held by thatprovider, unless such deletion is prevented by applicable law.

1

See also the earlier section on retention requirements for data and technology.

2

See also the next section on personal control and privacy rights.

The Good Health Pass Interoperability Blueprint

42

Finally, control of individual data also encompasses portability rights. GHP health credentials and passes
are designed to be “portable”, with users able to present them to different verifiers. Nonetheless, each
GHP solutions provider should evaluate on a continuing basis the technical feasibility of individual rights
of portability with respect to the particular personal data stored by that provider.

5.2.11.2		 Recommendations
1. Individuals MUST retain control of their personal data in GHP-compliant health credential and passsolutions for international travel.
2. Individuals MUST be able to exercise their rights to access and correction of personal datacontained within GHP solutions, or be provided appropriate mechanisms to request such accessand correction.
3. Individuals MUST be able to delete their personal data within GHP solutions, unless such deletion isprevented by applicable law.
4. GHP solutions providers SHOULD address individual rights of portability by evaluating the technicalfeasibility of portability mechanisms or evaluating how portability addresses such rights.

5.2.12		 Problem #10: Accountability for security &		 privacy requirements
5.2.12.1		 Problem Description
Accountability of GHP solutions providers means that all entities in the health pass ecosystem takeresponsibility for Privacy by Design and Security by Design and the recommendations provided in thisdocument.
Accountability cannot be demonstrated without producing some form of pertinent and persuasive
evidence that such requirements have been met.
The Privacy by Design and Security by Design requirements and recommendations cover a large numberof areas with clear levels of compliance. There is no accountability from these recommendations without
evidence.
In order to give evidence a number of activities need to take place which are described next.
It should be noted that accountability is an iterative process of developing and continuously assessing
and improving evidence that GHP solutions comply with Privacy by Design and Security by Design
recommendations.

5.2.12.2		 Good Health Pass Design Requirements & Considerations
Good Health Pass solutions for international travel – in order to meet Privacy by Design and Security by
Design requirements – create, execute, audit, and report on the following:
1. Risk Assessment Report, including legally required Privacy Impact Assessments or Data Protection
Impact Assessments for solutions that collect personal data.
2. Code of Conduct Compliance3. Consent Receipt Management Plan
Organizations MUST do self-assessments against the stated recommendations, and MAY publicly
disclose the results of those assessments, as well as remediation plans, if any.
A thorough information technology risk assessment is a systematic analysis by an organization to ensure
it considers the negative outcomes and threats under its purview. GHP solution providers MUST perform

The Good Health Pass Interoperability Blueprint43

a risk assessment which MUST consider security and privacy risks. The privacy assessment MAY be
in the form of a Data Protection Impact Assessment (DPIA) or if following ISO 29134 Privacy Impact
Assessment (PIA). For information security assessment the ISO 27005 MAY be followed.
GHP solutions that collect personal data MUST conduct a Privacy Impact Assessment or a Data
Protection Impact Assessment, when it is required by applicable law (e.g., GDPR).
GHP solutions SHOULD maintain proof that an individual has read a GHP privacy notice OR that they
have provided consent for the processing of their personal data. An example demonstration to anindividual of their privacy rights MAY be addressed in a consent receipt (see for instance the Kantara
Consent Receipt Specification v1.1.0) which is equivalent to a privacy policy and captures the proof ofconsent to the individual, as well as helps demonstrate to authority that consent has been given.
Consent receipts are beneficial for a number of other reasons, including increasing transparency. They
can serve as an evidence, notably In cases of invocation of rights (e.g., right to be forgotten).
If personal data is collected by the verifier, an additional consent MUST be presented to the individual.

5.2.12.3		 Recommendations
1. GHP solutions providers MUST disclose the information security and privacy standards andguidelines that they are following.
2. A Code of Conduct self-assessment against the GHP requirements MUST be conducted andevidenced. An external assessor SHOULD be used to perform the assessment to provide an
impartial review of the compliance.
3. All Zones MUST conduct a Data Protection Impact Assessment or Privacy Impact Assessment toensure privacy risks are identified and mitigated.
4. All Zones SHOULD conduct a self-assessment to make sure data minimization requirements are
met. Zones 2 and 3 passes MUST be data minimized.
5. If Zones 2 and 3 processes trigger applicable legal requirements (e.g., due to biometric data usage)a Data Protection Impact Assessment MUST be conducted to identify and mitigate privacy risks.
6. A privacy notice indicating the process to exercise privacy rights and how privacy information isprocessed, shared and protected MUST be given by the Issuer and Verifier.
7. For Zone 1 an evidence of consent or privacy notice, such as a consent receipt, SHOULD be
maintained and provided to the individual upon request. Similar evidence of consent or notice MAY
be provided by Zone 2 and 3 organizations.
8. Holders MUST have the ability to remove consent, where allowed by regulation, and this MAY takewhatever form is allowed within the jurisdiction for consent revocation (e.g., via email, letter, orother means).

5.2.13		 Additional Recommendations
The aforementioned requirements, considerations and recommendations provide a number of principles
and practical steps to achieve Privacy by Design and Security by Design. Both are key prerequisites for
GHP providers to accomplish their ultimate objective: to provide interoperable, effective, safe and secure
GHP technology solutions that are privacy-protecting and place the individual at the center of the design.
Ultimately, ensuring that equity and inclusion, privacy, fundamental human rights, and other civil liberties
are protected is key to ensure the successful uptake of GHP solutions.
The Privacy by Design and Security by Design recommendations included in this document provide arobust framework for GHP solutions to achieve Privacy by Design and Security by Design. GHP providers

The Good Health Pass Interoperability Blueprint

44

MUST comply with all relevant security, privacy and data protection laws and regulations and MUST be
designed and implemented to enhance privacy, support data minimization and other fundamental privacy
and security principles.
Privacy by Design and Security by Design is a collective responsibility of all actors in the health passecosystem; privacy, data protection, and security is as strong as the weakest link of the entire ecosystem.
Therefore it only works if all actors have the same vision on privacy, data protection, and security of data.

The Good Health Pass Interoperability Blueprint45

5.3 Recommendation #3: Identity Binding
5.3.1

Introduction to this Interoperability Challenge

For a health credential to be trustable at the point of presentation, the verifier MUST be able to determine
the level of confidence that the presenter of the health pass is the legitimate subject of the health pass
(i.e. is it really Jane Doe presenting Jane Doe’s health status?).
This challenge may seem trivial for the credentials that are carried in wallets and purses to identify
ourselves (e.g., driving licenses or passports). That is because we go through elaborate in-person identity
proofing processes to obtain those credentials. As a result, those credentials end up carrying a great
deal of personal data (e.g., name, address, birthdate, hair color, eye color) including biometric data (e.g.,
picture, fingerprint, facial scan) that has been verified face-to-face.
This rich set of identity data on a printed credential makes authentication relatively easy when done inperson (such as passing through an airport security checkpoint). However:
1. It can be difficult or impossible to use that same information to authenticate an individual remotely,over a digital connection (such as using a website or a smartphone application).
2. Aggregating all of this identifying information in a digital credential creates an unnecessary privacy
risk vector: e.g. the GDPR, Identifying information should be protected securely and minimized tothe extent needed to perform adequate authentication.
3. Many individuals in the world – over 1 billion – do not have access to these forms of strong identity
documents, or any form of legally-recognized identity at all.
While the International Health Regulations recommend binding the identity of an individual to theirInternational Certificate of Vaccination (or “yellow card”) by their name, date of birth, gender, nationality
and national identification document, in the context of the COVID-19 pandemic, few health authorities
are mandating an in-person identity authentication process – let alone a rigorously secure one – prior toadministering a COVID-19 test or vaccination. In fact, some health authorities have rejected, on ethicalgrounds, any requirement for proof of identity as a prerequisite for receiving a test or vaccination.
This raises critical questions about how best to manage identity proofing from the point of healthcaredelivery through to point of presentation, and how best to mitigate risks associated with identity fraud.

5.3.2

Objective of this Drafting Group

This section provides recommendations for identity binding across three zones in the Good Health Pass
(GHP) ecosystem. We also address identity disambiguation – the concept that not all issuers will know all
verifiers’ identity requirements – to enable a flexible framework for trust.

The Good Health Pass Interoperability Blueprint

46

Figure 5: Identity binding and authentication zones in theGood Health Pass ecosystem
Specific identity binding challenges must be solved in each of the three zones:
1. In Zone 1, the GHP ecosystem MUST be able to accommodate the complete spectrum of identity
binding strength – from no identity binding at all (e.g., giving a free COVID-19 test to a refugee) to apatient with full biometrics and an extensive electronic health record (EHR) at a modern hospital.
The strength of this initial binding can be described by assigning the level of assurance (LOA).
Levels of assurance are described in various national and international standards documents
including: 1) ISO/IEC 29115; 2) Pan-Canadian Trust Framework; 3) eIDAS; and 4) the NIST 80063 series. The latter establishes some of the most widely referenced standards for LOA for identity
proofing, including the Identity Assurance Level (IAL) as described in NIST-800-63A and theAuthenticator Assurance Level (AAL) described in NIST-800-63B.
2. In Zone 2, GHP credential issuers MUST perform identity authentication of the holder to a sufficient
LOA prior to issuance of the credential. The LOA achieved SHOULD also be described in the issued
credential itself.
3. In Zone 3, GHP credential verifiers determine the LOA to which they require identity authenticationof the holder at the time the credential is presented. The verifier can use this LOA, together with theissuance LOA, to apply its own policies (or the policies of the trust or governance framework underwhich it is operating) to determine the trust to place in the credential.
While many specialized technologies (such as biometric authentication) and business processes (such as
identity proofing training) exist to provide higher levels of assurance, they are not always needed or usedin healthcare delivery, which means some of these tools may be difficult, if not impossible, to implement.
Thus, the GHP ecosystem MUST support:z Low-tech or no-tech identity binding solutions alongside high-tech means.
z Options for supervised remote proofing using secure video conferencing services.
z Remote or self-administered testing to provide the greatest impact and reach.
z Healthcare data systems that are not designed for the purpose of supporting a health credential
service.
In short, GHP-compliant credentials MUST be able to describe any level of identity proofing at the time oftesting – from none to fully verified biometrics.

The Good Health Pass Interoperability Blueprint47

5.3.3Background

Identity binding is the ability to link the presenter of an identity claim to the claim itself. In the context ofverifiable health credentials this is typically done when:

5.3.3.1 Issuing an identity credential
In many instances this is a government function where an identity proofing process is used to:z Resolve a claimed identity to a single, unique identity within the context of the population of users
z Validate that all supplied evidence is correct and genuine
z Validate that the claimed identity exists in the real worldz Verify that the claimed identity is associated with the real person supplying the identity evidence
The rigour of the identity proofing process is quantified in the Level of Assurance (LOA) (see ISO/IEC
29115, Section 8.1.2) and often correlates with the Identity Assurance Level of the credentials provided
and their underlying identity proofing processes (refer to NIST 800-63A Section 4.7 or ISO 29115 Section
6.5 for examples of IALs).
Identity credentials with relatively high enrollment LOAs are jurisdictional ID cards and national passports
where identity proofing is done in-person, typically with biometric identifiers to deduplicate within the
population, and breeder documents are source-checked. Conversely, shoppers’ affinity cards require avery low enrollment LOA. The acceptable enrollment LOA for an identity credential is a business decision
based on the risk appetite of the relying party for the credential’s primary purpose.

5.3.3.2 Presenting an identity credential to receive a service
In the context of verifiable health credentials, this MAY be at the point of vaccination or test, the bordercrossing point, at an employer’s facility, at an educational institution, etc.
The viability of the verifiable health credential relies on the accreditation of the issuer AND their ability toauthenticate the identity of the subject to the level required by verifiers.
Authentication, like identity proofing, has varying levels of assurance depending on the methods used.
See ISO/IEC 29115 Section 6.5 for examples of Authentication LOAs or Assurance Levels.
Authentication processes with relatively high Authentication LOAs are in-person (or remote supervised).
They MAY include one or more biometrics, and one or more cryptographic devices. Conversely, a4-digit PIN corresponds to a relatively low Authentication LOA. The Authentication LOA best suited forauthenticating an identity claim is a business decision based on the risk appetite of the relying party.

5.3.4

Levels of Assurance

ISO/IEC 29115 Entity Authentication Assurance Framework provides a framework for managing
authentication assurance in a given context. In particular, it:z specifies four levels of authentication assurance;z specifies criteria and guidelines for achieving each of the four levels of authentication assurance;
z provides guidance for mapping other authentication assurance schemes to the four LOAs;z provides guidance for exchanging the results of authentication that are based on the four LOAs; andz provides guidance concerning controls that should be used to mitigate authentication threats.
There are four LOAs defined in ISO/IEC 29115 which are:

The Good Health Pass Interoperability Blueprint

48

There is minimal confidence in the asserted identity of the entity, but some confidence
that the entity is the same over consecutive authentication events.

LOA 1

This LOA is used when minimum risk is associated with erroneous authentication.
There is no specific requirement for the authentication mechanism used; only that itprovides some minimal assurance. A wide range of available technologies, including thecredentials associated with higher LOAs, can satisfy the authentication requirements forthis LOA. This level does not require use of cryptographic methods.
There is some confidence in the asserted identity of the entity. This LOA is used whenmoderate risk is associated with erroneous authentication. Single-factor authenticationis acceptable.

LOA 2

Successful authentication SHALL be dependent upon the entity proving, through asecure authentication protocol, that the entity has control of the credential.
Controls SHALL be in place to reduce the effectiveness of eavesdropper and online
guessing attacks. Controls SHALL be in place to protect against attacks on stored
credentials.
There is high confidence in an asserted identity of the entity. This LOA is used where
substantial risk is associated with erroneous authentication.

LOA 3

This LOA SHALL employ multi-factor authentication. Identity proofing procedures
SHALL be dependent upon verification of identity information. Any secret informationexchanged in authentication protocols SHALL be cryptographically protected. There
are no requirements concerning the generation or storage of credentials; they MAY be
stored or generated in general purpose computers or special purpose hardware.
There is very high confidence in an asserted identity of the entity. This LOA is used whena high risk is associated with erroneous authentication.

LOA 4

LOA 4 provides the highest level of entity authentication assurance defined by thisstandard. LOA 4 is similar to LOA 3, but it adds the requirements of in-person identity
proofing for human entities and the use of tamper-resistant hardware devices for the
storage of all secret or private cryptographic keys. Additionally, all personally identifiable
information (PII) and other sensitive data included in authentication protocols SHALL be
cryptographically protected.

Levels of assurance are described in other national and international standards documents including:
1) Pan-Canadian Trust Framework; 2) eIDAS; 3) the NIST 800-63 series; 4) the Trusted Digital Identity
Framework; and 5) UK GPG-45. However, we will refer to the ISO guidance throughout this document,
which can be mapped to other standards.

5.3.5

Case Study: Identity Binding for COVID Health Passes in
the United Kingdom

Taking a high-level look at enrollment and authentication processes in the United Kingdom highlights how
identity is used in healthcare today, both generally and in the context of COVID-19.
It is important to note that other countries’ health care systems work very differently. Identity binding for
health passes needs to operate within these different constructs.

5.3.5.1 Patient enrollment
Patients in the U.K. obtain first-line healthcare through a General Practitioner (GP). GP surgeries are
private businesses contracted to the National Health Service through their local Clinical Commissioning

The Good Health Pass Interoperability Blueprint

49

Group. Patients are enrolled onto the list of their local GP surgery. While GPs will often ask for proof ofidentity and address, there is no formal requirement for identity verification. Indeed, GPs cannot decline
to register a patient due to a lack of proof of identity or address.3
Once enrolled, when attending an appointment in-person, the patient will be required to confirm theirname and date of birth. Again, there is no requirement for identity verification nor any authentication
other than matching the self-asserted information with the patient record.

5.3.5.1.1

WHY IS THIS IMPORTANT?

1. Vaccinations obtained in the course of public health programmes, such as the COVID-19 vaccination
rollout, MAY have no demonstrable identity verification for some users.
2. Health pass providers MUST NOT assume users have been rigorously authenticated at the point ofcare.

5.3.5.2

DIGITAL HEALTH RECORDS

Patients are able to access online services such as:z contacting their GP for advice and support
z ordering repeat prescriptions
z seeing parts of their health record, including information about medicines, vaccinations and test
resultsz seeing communications between their GP surgery and other services, such as hospitals
z booking, checking or cancelling appointments
There are two ways in which patients can enrol for access to online services.
1. They enroll for an NHS ID online by proving their ID using a government document – their verified
data is then matched against their patient record, and they get credentials (username, password
and mobile one-time passcode) for future access.
2. They go via their GP who registers them for online access, making the link to their patient record
and issuing them with credentials for access.

5.3.5.2.1

WHY IS THIS IMPORTANT?

Credentials obtained from a health record should contain identity data that can be matched with theidentity proofing undertaken by the health pass provider.

5.3.5.3

COVID-19 VACCINATIONSIn the U.K., COVID-19 vaccinations are offered for free, with rollout prioritising the most clinicallyvulnerable. Patients are contacted by their GP surgery as, based on their patient record, they fall into thepriority grouping being called forward on a national basis. Once invited, patients register either online orby phone giving their details to match to their patient record. Vaccinations are being provided through:z local hubs covering multiple GP surgeries
z mass vaccination centresz satellite locations in premises such as pharmacies
This means that for the majority of patients, they will be vaccinated somewhere other than the GP surgery
they are registered at.
The NHS has produced a COVID-19 vaccination record card which is issued to the patient when theyattend for their vaccination. The card acts as a reminder for their second appointment for a two-dose3

https://www.nhs.uk/nhs-services/gps/how-to-register-with-a-gp-surgery/

The Good Health Pass Interoperability Blueprint50

regime. It is not intended to be used as evidence of being vaccinated. The name of the patient is the only
identity binding on the record. The name of the vaccine given, the batch number and the date given isrecorded.

Figure 6: Vaccination card
As well as being provided with the physical card, the details are electronically recorded against their NHS
patient record.

5.3.5.3.1

WHY IS THIS IMPORTANT?

1. The use of identity tools provided by health pass applications SHOULD NOT expect to be included
within a public healthcare process.
2. Proof of vaccination MAY be obtained from the healthcare systems post the point of treatment.

5.3.5.4 COVID-19 Testing
Public health testing is available through an online or phone booking system. This is available through a
network of testing centers offering drive-up or walk-up service, additionally home testing is provided bypost. In areas with surges of cases or where new variants are of concern, testing with no priorappointment is also available. Patients applying online must provide their name, plus a mobile number toreceive their results. An email address is also required for a home testing kit. Public health testing is not to
be used for activities that require proof of a negative test.
Testing for proof of a negative result for international travel purposes is provided by the private sector.
Governments have published criteria for providers of these tests to develop “Trust Lists” that passengers
must obtain their test results from4 5.
These private sector providers offer both in-person and at home testing services. The personal datarequired varies from provider to provider. Some require only limited contact information, name and email,where others also request passport details.

5.3.5.4.1 WHY IS THIS IMPORTANT?
1. Public health testing SHOULD be assumed to be for the identification of positive cases rather thanproof of a negative test. Therefore, the requirements for identity binding MAY NOT be of primaryconcern should a credential be issued.
2. Health pass providers MAY need to provide the ability for private sector testing providers toauthenticate the user of the Health Pass (e.g., by securely displaying a photo, name and date ofbirth of the user).
3. Private sector health providers MAY need to align their own identity proofing and authentication
processes, where used, with those of the health pass providers.
4

https://www.gov.uk/guidance/self-declare-as-a-private-sector-covid-19-testing-provider

5

https://www.cdc.gov/coronavirus/2019-ncov/travelers/testing-international-air-travelers.html

The Good Health Pass Interoperability Blueprint51

4. Health pass providers MAY need to support the use of identification evidence related to the usecase for which the credential is being obtained (e.g., a passport for a travel use case, a proof of age
card for a hospitality use case, matching attributes such as name and age for an event use case).
5. Health pass providers MAY need to support facial biometric binding to the individual where thetechnology requirements allow to include those without provable identity.

5.3.5.5 Coronavirus testing before you travel to England
International arrivals to England (other nations within the U.K. may have different rules) are required tocomplete a Passenger Locator Form.
Passengers are required to have proof of a negative test result6. This proof can be in the form of a printed
document or an email or message that can be shown on a phone. The test result must be in either English,
French, or Spanish. Translations are not accepted.
The original test result notification must include the following information:z your name, which should match the name on your travel documents
z your date of birth or age
z the result of the testz the date the test sample was collected or received by the test provider
z the name of the test provider and their contact details
z confirmation of the device used for the test, or that the test was a PCR test

5.3.5.5.1

WHY IS THIS IMPORTANT?

Health pass providers should be able to meet the identity binding policy of the use case for which thehealth credential is being used.

5.3.6

Achieving Interoperability for Identity Binding Acrossthe Zones

In order for identity binding of digital health credentials and passes to be interoperable, participating
ecosystem partners MUST either all agree on processes for identity binding within each zone and how
those processes will be represented digitally (as was done by ICAO and its members for passports,
e-passports, and Digital Trave Credentials), or because different countries, regions, or other jurisdictions
may have differing requirements, there MUST be a way for verifiers to publish their requirements so thatissuers can obtain country-specific requirements and update their process accordingly.

5.3.6.1 Zone 1: Identity authentication at the point of COVID-19
		 Vaccination or Testing
As we have seen from the example of the United Kingdom, identity authentication processes vary at the
point of COVID-19 vaccination or testing.
Even though passports or government-issued IDs are required for international travel, and even while
verifiers may hope for high-assurance, robust identity proofing processes at the point of vaccinationor testing, this may not be in the best interests of the health care provider or the patient. It would be
exclusionary – and could potentially run contrary to public health aims – to require patients to present a
passport in order to access testing or vaccination.

6

https://www.gov.uk/guidance/coronavirus-covid-19-testing-for-people-travelling-to-england

The Good Health Pass Interoperability Blueprint52

As such, in Zone 1, the Good Health Pass ecosystem MUST be able to accommodate the complete
spectrum of identity binding strength – from no identity binding at all for a refugee who may not haveofficial identity documentation to authenticating a patient, in-person, with full biometrics using a tamperresistant hardware device for cryptographic keys and an extensive Electronic Health Record at a modern
hospital.
This said, where test results or vaccination status is being sought specifically for the purposes ofinternational travel, the ID document intended to be used for international travel SHOULD be presented
to the healthcare provider.
Regardless of what form of identity proofing is performed, the Identity Assurance Level MUST berecorded in the transaction so that verifiers can assess the corresponding risk of identity fraud.

5.3.6.1.1

WHY IS THIS IMPORTANT?

1. The verifier MUST convey its identity assurance requirements to the pool of Issuers so they
can determine whether to change their issuance processes. These identity requirements are
enumerated as Levels of Assurance (LOA) associated with the identity document issuance process(Enrollment Phase per ISO/IEC 29115; Identity Assurance Level per NIST 800-63A) and with theauthentication process (Authentication Phase per ISO/IEC 29115; Authenticator Assurance Level
per NIST 800-63B).
2. Health pass providers MUST augment the deficiencies of identity binding in public healthcare
processes for the fulfilment of private sector use cases that need greater assurance.
3. Health pass providers MAY support differing assurance levels no or low identity and authentication
provided that this information is conveyed to the Verifier.
4. The Issuer SHOULD provide the enrollment LOA of the identity document used in Zone 1 along withassociated Authentication LOA of the authentication process where:
4.1. enrollment LOA – reflects the level of identity proofing and identity verification that is
performed when enrolling with an identity provider which typically results in the issuance ofan identity credential (e.g., Passport Agency)
4.2. Authentication LOA – reflects the level to which the subject can demonstrate that they are inpossession and/or control of a credential in order to establish confidence in a claim of identity.

5.3.6.2 Zone 2: Identity authentication at the point of COVID-19
		 credential issuance
In some jurisdictions, credential issuance could occur contemporaneously with the vaccination or test.
If conducted in a single uninterrupted process (i.e. the person administering the vaccine in a patient’s
arm also being the identity authenticator and credential issuer), there would be limited possibility for thecredential to be issued to the wrong individual.
But, often, these processes will be distinct, with issuance of the credential occurring after the healthprocess undertaken. As described in the U.K. example, a record of vaccination may exist within the healthsystem. A patient should be able to access their own health record and obtain a credential as proof ofprior vaccination.
If Zones 1 and 2 are separated, the identity binding process is referred to as “late binding”, it is incumbent
on the process to ensure chain of custody – that the health information is bound to the correct individual
across zones. Having performed identity proofing in Zone 1, authentication is then used in Zone 2 toensure that the health credential is being issued to the correct individual.

The Good Health Pass Interoperability Blueprint

53

In Zone 2, GHP credential issuers MUST perform identity authentication of the holder to a sufficient
Authentication LOA [based on the destination country’s rules – where applicable] prior to issuance of thecredential. The level of authentication assurance will vary depending on how these steps are administered.
It is recommended that the GHP credential SHOULD include identity document information and both theenrollment LOA of the document presented and the Authentication LOA achieved when authenticating
the identity claim; i.e. identity binding, for zone 1 and 2, even if it’s the lowest possible level on zone 1, toenable a trusted risk assessment for zone 3.
Health care providers MAY issue the credential using technology integrated into the health pass provider(e.g., a QR code scanned by the health pass application), via SMS or email, via the health care systems(e.g., digital health records), or using paper records.
With home testing, strong identity authentication MAY be required in order to obtain the test kit, though
the chain of custody is far weaker as to who the kit is used on. Without remote supervision being used
for the entirety of the process, there is scope for fraud to occur. This can be mitigated to some degree
by requiring authentication of the user to accept the test kit. For example, using possession of a mobile
device as an authentication factor so that the results of the test are only issued to a specific device.
The use of multi-factor authentication that includes a biometric factor such as the photo from a passport
may be desirable for an international travel use case. To enable such a scenario, biometric information(e.g., facial image) MAY be added to the credential data. Performing biometric authentication in Zone 3
and validating the custody chain will enhance assurance while minimizing the impact on the user’s privacyin the process.
Consideration should be given to the use of biometric technology. While biometric authentication isreadily available for individuals with smartphones, additional technology investments might be requiredfor individuals with little or limited access to smartphones.

5.3.6.2.1

WHY IS THIS IMPORTANT?

1. Health pass providers MAY need to match the identity data from their own proofing process withidentity data in a credential obtained from a health system.
2. Health pass providers MAY need to account for the chain of custody in the information presented to
the verifier in order that they can implement their own risk mitigations.

5.3.6.3 Zone 3: Identity authentication at the point of COVID-19
		 credential validation
In Zone 3, GHP credential verifiers validate the GHP credential by checking the authenticity, integrity, andrevocation status of the credential and then determining if the presenter of the credential is the legitimate
subject of the credential. Being able to determine what has occurred – from the point of health careprovision to the issuance of the corresponding GHP credential – enables the implementation of business/
operational policies within the verifier domain.
This can be done with digital or physical identity credentials where the verifier MAY use biometric
information in the credentials and MAY also review the issuer’s levels of assurance during the identity
process to ensure that it meets the required enrollment LOA and Authentication LOA – where applicable.
Leveraging the authentication used to issue the credential at the time of presentation can ensurethat the subject of the credential is known and can be trusted. If issuers have established multi-factor
authentication using a biometric factor bound to the holder, the verifier MAY require the holder toauthenticate using the same means in order to prove they are the subject of the credential.

The Good Health Pass Interoperability Blueprint

54

Alternatively, verifiers MAY use the identity information bound to the credential to match with theirown data or the additional presentation of an identity document. For a travel use case, this could be thepassenger named on the boarding card or the details of a passport or regional travel document.
While tools exist to provide high levels of assurance, such as biometric authentication, it should berecognized that the following primary considerations for healthcare may make such tools difficult if not
impossible to implement:
inclusion and accessibility needs mean that low, or no tech solutions MUST work alongside high-techmeans
z those with limited evidence of their identity MUST be served with equivalence to those with thestrongest formsz public health needs MAY require remote and self-administered testing to provide greatest impact
and reachz primary systems for recording data are established health systems that extend far beyond the
purpose of a health pass service
Given this, verifiers MAY choose to adopt additional risk mitigation practices and, where suitable, accept a
degree of risk associated with lower identity assurance levels.

5.3.6.3.1

WHY IS THIS IMPORTANT?

1. Health pass applications SHOULD allow the verifier to understand, to the extent possible, what
identity binding has occurred in Zones 1 and 2.
2. Verifiers SHOULD expect to fill gaps in the identity binding process, particularly for no/low
assurance and no/low technology implementations. For example, manual cross reference of thehealth credential with a physical identity document at the point of acceptance.
3. If countries specify minimal identity assurance levels (enrollment and authentication), thosecountries SHOULD publish those requirements, making it possible for individuals to bring therequisite identity information to the point of healthcare delivery and for healthcare providers andcredential issuers to perform the requisite identity authentication and binding – and record it in the
GHP credential.

5.3.7

Problem #1: Health pass solutions must work with theexisting diverse healthcare system

5.3.7.1

Problem Description

Identity binding is primarily a concern of the providers of health pass solutions. Healthcare providers needto prioritise access to healthcare, and if health passes are to be inclusive, it MUST be recognised that:z Healthcare providers, particularly in the public health domain, cannot present unjust barriers basedon a patient’s ability to prove their identity, or their access to or capability to use technologyz Access to health care is the primary concern, ability to provide proof downstream is secondary. Thismay create undesired circumstances for the verifier of a health pass credential that they will have to
mitigate. Health pass providers need to give them the information to enable them to do so.
z There is more ability to influence identity binding for health credentials obtained for the specificpurpose of the verifier use case – for example, obtaining a COVID-19 test prior to international
travel.

The Good Health Pass Interoperability Blueprint55

5.3.7.2 Good Health Pass Design Requirements & Considerations
Healthcare infrastructure (e.g., IT, processes) is mature and diverse, and changes needed to support Good
Health Passes may be cost and/or time prohibitive. The recommendations that follow will allow for these
constraints while focusing on steps to facilitate the safe resumption of international travel.

5.3.7.3 Recommendations
5.3.7.3.1

OVERALL RECOMMENDATIONSProviders of health pass solutions SHOULD perform identity binding between the identity credential
presented and the subject of the health pass where possible. The use of biometric authentication MAY
provide a useful foundation from which identity binding can be layered as required for the use of thehealth pass.
Health pass providers MUST operate with the healthcare system, not the other way round. This meansthat they will have to fill gaps in identity proofing and authentication undertaken in the healthcare domain
through innovative controls in their own domain. They MAY fill these gaps by providing matching ofidentity data from their own proofing process with the identity data received from the healthcare systems.
Health pass solutions SHOULD implement identity binding by offering identity proofing andauthentication capabilities to fulfill variations and gaps that exist in healthcare providers and verifiers
across the three zones described.

5.3.7.3.2

PHASE ONE (30 DAY HORIZON)

Health pass solutions SHOULD document the existing identity binding process including what
information is recorded and/or reviewed at health pass issuance and/or verification.

5.3.7.3.3

PHASE TWO (90 DAY HORIZON)

Health pass solutions SHOULD review guidance on GHP-certified issuance or verification sub-systems(e.g., APIs) that can augment existing IT to meet GHPC identity binding recommendations.

5.3.7.3.4

PHASE THREE (180 DAY HORIZON)

Health pass solutions SHOULD implement GHP-compliant issuance or verification sub-systems (e.g.,APIs) that meet GHPC identity binding recommendations which includes documenting the full name,date of birth, identity document type, country of issuance, and identity document number7 presented tothe healthcare provider which SHOULD be the passport the subject plans to use for international travel.
If not the passport to be used for international travel, another government-issued identity document witha photo SHOULD be used so that the healthcare provider can ensure that the presenter of the photo ID isthe authorized holder of the ID and the identity information matches what is in the health record.
Electronic passports (e-passports) themselves are supposed to align to ICAO’s Traveler Identity
Programme (TRIP) process and, where the photo is taken live, have a high LOA. Where the photo is
captured by the subject and mailed to the issuing authority, the e-passport has a lower (i.e., medium)LOA.
7

Per recommendations in ICAO DOC 10152

The Good Health Pass Interoperability Blueprint56

5.3.8

Problem #2: Identity Binding must support low or notechnology solutions

5.3.8.1 Problem Description
Recognition is needed that solutions requiring higher-end technology need to interoperate with low- or
no-technology solutions at the issuer and verifier(s) points of the journey. The same is true for solutions
that provide higher standards of identity proofing and authentication, these MUST equally interoperatewith low assurance implementations.
If lower assurance identity binding was used at issuance, the verifier MAY be required to take additional
actions, such as cross referencing the identity details of the subject of the health credential. Solutions
leveraging tools such as smartphones, document verification and biometric facial matching can provide
a more seamless and reliable verifier experience. Health pass solutions offering this three-way binding
between the user, their identity evidence and the health credential are desirable, though need to allow
for interoperability with more simple health passes, including those utilising paper as the means ofpresentation.

5.3.8.2 Good Health Pass Design Requirements & Considerations
Because the goal is to integrate with low- or no-technology health solutions, the health pass validity
related to identity binding MUST be self-contained. Therefore, health pass solutions SHOULD document
the identity binding process at the time it was issued and share the related identifying attributes as partof the health pass so that verifiers can assess risk of identity fraud.
There are two scenarios that SHOULD be considered:
1. The no technology use case, where a paper-based health pass is presented and the identifying
attributes contained in the health pass are validated with some form of official ID such as a passport
or driver’s license.
2. The off-line use case, where a digital or paper-based health pass is presented that can be digitally
verified using cached public key information from a trust registry. The identifying attributes
contained in the health pass are validated with some form of official ID such as a passport or driver’s
license.

5.3.8.3 Recommendations
5.3.8.3.1 OVERALL RECOMMENDATIONSVerifiers SHOULD be provided with information on the identity binding that has taken place. This allows
identity binding activities to be stepped-up by the verifier from no or low levels of identity binding as
required to meet their use case.

5.3.8.3.2 PHASE ONE (30 DAY HORIZON)
Health credential and pass solutions SHOULD document the existing identity binding process, including
what information is recorded and/or reviewed, at health pass issuance and/or verification points.

5.3.8.3.3 PHASE THREE (180 DAY HORIZON)
Health pass solutions SHOULD implement GHP-compliant credential issuance or verification subsystems (e.g., APIs) that meet GHPC identity binding recommendations.

The Good Health Pass Interoperability Blueprint57

5.3.9Problem #3: Globally agreed standards for the levels ofconfidence in identity binding are required

5.3.9.1 Problem Description
GHP solutions operate at an international level. There are multiple local, national and international
standards on Identity Proofing LOAs and Authentication LOAs that are already established across thedifferent jurisdictions.
In order to work with the currently established standards that different governments and identity
providers use today rather than forcing them to adopt a new standard, the GHP EGF needs to work withmultiple standards and enable interoperability across them. So for example a GPG-45 Authentication
LOA 2 medium identity binding for zone 1 & 2 in the U.K. can be accepted by a verifier in zone 3 in the U.S.
where they require an equivalent Authenticator Assurance Level (AAL), as defined in NIST 800-63B, or
lower (i.e., AAL 1).

5.3.9.2 Recommendations
5.3.9.2.1 OVERALL RECOMMENDATIONS
To create consistency and full disclosure, the degree of identity assurance and authentication is highly
RECOMMENDED. In reviewing generally accepted standards for levels of identity assurance andauthentication, we RECOMMEND adopting ISO/IEC 29115:2013 (revised as intact in 2020) to categorize
distinct levels of assurance for identity proofing and authentication. While we believe that other standards
have advanced ISO/IEC 29115 as it directs specific jurisdictional applications, this standard is established
to be the most widely used at an international level. The standard also provides guidance for mapping
other authentication assurance schemes to the four levels of assurance, providing for the most flexible
option (satisfying our GOOD objective).
While other standards MAY be used in a particular jurisdiction, they MUST map their establishedstandards to the international ISO/IEC 29115 identity and authentication levels of assurance as defined intheir respective standards to ensure interoperability.
Both the identity proofing and authentication LOAs used in the identity binding process SHOULD bepresent across the three zones.
Health pass providers MAY also offer tools and services to the healthcare provider, such as the ability forthe user to show or share their verified identity details in an easy to integrate way. Similarly, they SHOULD
provide ease of integration into the verifiers’ systems.
Healthcare is a multi-provider domain. Health pass providers SHOULD ensure that documentation ofidentity binding is implemented consistently across GHP-compliant solution providers so that Issuers inboth the public and private healthcare sectors and verifiers in all sectors can reliably utilise whichever
health pass solution a user presents.

5.3.9.2.2 PHASE ONE (30 DAY HORIZON)
Health Pass solutions SHOULD identify which identity and authentication assurance framework(s) areapplicable and what LOAs are possible to reach with the current system.

5.3.9.2.3 PHASE TWO (90 DAY HORIZON)
1. Health Pass solutions MUST map their existing identity and authentication assurance framework(s)to ISO/IEC 29115
2. Health pass solutions MAY extend or modify the IT systems and verification processes to achieve
the desired Levels of Assurance within ISO/IEC 29115.
The Good Health Pass Interoperability Blueprint58

5.3.9.2.4 PHASE THREE (180 DAY HORIZON)
Health pass solutions SHOULD achieve a certification of compliance from GHP to the LOAs supported.
This MAY be achieved by providing GHP with evidence of a valid third party audit when available.

5.3.10 Interoperability Testing Recommendations
1. Health pass solutions MUST ensure that they are able to consume identity binding information forthe commonly adopted standards defined above from credential Issuers.
2. Health pass solutions MUST ensure that they are able to interpret identity binding information forthe commonly adopted standards defined above for use in their business processes.
3. Health pass solutions MUST ensure that they are able to convey identity binding information for thecommonly adopted standards defined above to verifiers.

5.3.11 Additional Recommendations
5.3.11.1 Regulators (Governments)
Governmental jurisdictions SHOULD establish acceptance policy for identity proofing and authentication
by taking measures to ensure that Individuals are not excluded due to a lack of provable identity or accessto technology when defining requirements for presentation of health credentials

5.3.11.2 Standard Developing Organizations (SDOs) / Industry Groups		 (e.g. WHO, ISO, W3C, VCI, LFPH, ID2020, ToIP, DIF, IATA, ICAO, HL7)
1. Global standards bodies and industry groups SHOULD map to the ISO/IEC 29115 levels of
assurance.
2. Use of other jurisdictional standards MAY be used provided that they are mapped to the globallyinteroperable standard recommended by GHPC.

5.3.11.3 Issuers – Public (Public health providers)Public health providers SHOULD include identity information of the subject to comply with data
standards for health credentials issued to Good Health Passes.

5.3.11.4 Issuers – Private (Private health providers)Private health providers SHOULD align their own identity processes with health passes by utilisingidentity processes provided by or aligned to those of the GHP providers. They SHOULD include identity
information of the subject to comply with data standards for health credentials used to create Good
Health Passes.

5.3.11.5 Verifiers / Buyers of Health Pass solutions (Airlines; Airports;
		 Border control)
Verifiers of health pass solutions SHOULD establish risk mitigation practices that consider thecomplexities for issuance of health credentials and the variations in the level of confidence they can takefrom identity binding. Their identity binding practices SHOULD be in compliance with the requirements ofa governance framework.

The Good Health Pass Interoperability Blueprint59

6

Credential Recommendations

The Good Health Pass Interoperability Blueprint60

6.1 Recommendation #4: Standard Data Models
and Elements
6.1.1

Introduction to this Interoperability Challenge

COVID-19 health data comes from multiple sources and in different formats, based on who, where,
and how that data is collected in a given jurisdiction. But as with passports and payment cards, fullyinteroperable digital health pass systems need to support a common data model for data exchange,
including specifying standard attributes and forms that can be supported by specific use case
implementations.
The Good Health Pass Data Models & Elements recommendations are grounded in the work put forward
by several cross-industry efforts, including:z COVID-19 Credentials Initiative (CCI) [Linux Foundation Public Health (LFPH)], which has
established a task force to develop form and schema specifications, Codes of Practice, technicalguidelines, JavaScript Object Notation (JSON) code, and related components. This CCI work
includes full reference to the eHealth Network’s guidelines for COVID-19 certificates.
z W3C Credentials Community Group (CCG)’s Vaccination Certificate Vocabularyz Smart Vaccination Certificate Working Group at World Health Organization (WHO) (dissolved)z Canadian COVID Credentials Consortium (C4)z International Air Transport Association (IATA): IATA Travel Pass Initiativez International Civil Aviation Organization (ICAO)z FHIR Focus Group at Trust over IP Foundation (ToIP)z Vaccination Credential Initiative (VCI): SMART Health Cards Frameworkz Centers for Disease Control and Prevention (CDC): COVID-19 Vaccination ReportingSpecification (CVRS)z UK’s National Health Service (NHS): Testing for coronavirus (COVID-19) /Coronavirus COVID-19 vaccinesz ISO/IEC 18013-5 mdoc for eHealth
The Good Health Pass Collaborative (GHPC) would like to applaud the global efforts of all of these
initiatives – each of which reflects vast participation and collaboration from public health authorities,
private health vendors and consortiums, electronic health record (EHR) providers, pharma companies,
and major pharmacy chains (US).
Through an extensive evaluation of the above cross-industry initiatives, this group worked to develop a
set of data element recommendations that can accommodate requirements of different countries andjurisdictions around the world.

6.1.2

Objective of this Drafting Group

Given the global nature of health pass credentials and passes, the Good Health Pass ecosystem MUST
be technologically agnostic to all data ingestions. As such, this document focuses recommendations
predominantly on data elements, semantic harmonization, and common models for data exchange that
can help us work toward interoperability without putting an undue burden on existing health systems andworkflows.

The Good Health Pass Interoperability Blueprint61

6.1.3

Problem #1: Data Elements – Certificates, Credentials,
and Passes

6.1.3.1 Problem Description
In healthcare contexts, data is held in a number of places, such as laboratories, health information
systems, and clinical trial registries. In order for an issuer to create a credential or pass, based on therequirements of the activity they’re undertaking, these institutions must make a version of that data
available to that person in the form of a certificate or credential.
When creating standards for a globally-useable health pass, agreement on a minimum-necessary setof data, including how the data is named, organized, etc. is critical to ensuring interoperability. This
is of particular importance when considering that the sources of the data (e.g., the aforementioned
institutions) may collect or code data differently.
In general, a Good Health Pass (GHP) should only include the minimal set of information necessary toverify and confirm the holder’s vaccination, testing, or recovery status as required for a verifier to make aparticular trust decision. This is reinforced by Figure 7 from the Good Health Pass Guide to Key Concepts
and Terminology:

Figure 7: The four core terms for describing data containers for health data
used for travel

6.1.3.2 Good Health Pass Design Requirements & Considerations
Within the Good Health Pass ecosystem, a health credential attests that a COVID-19 test event or
vaccination event occurred and a health pass attests to the minimal set of data from one or more healthrecords required for a specific verifier or class of verifiers to make a particular trust decision.
In February 2021, the COVID-19 Credentials Initiative (CCI) Schema Task Force began comparing
data set recommendations from the cross-industry efforts listed above (see cross-reference links in
Appendix B for more details). This landscape began with the CDC’s Technical Standards and Reporting
Data – comprehensive documentation that contained recommendations beyond the minimum datarequirements for credentials and passes.
The Good Health Pass Interoperability Blueprint

62

When the World Health Organization published its core data set for the Smart Vaccination Certificate(renamed Digital Documentation of COVID-19 Certificate) in March 2021, and when the EU’s eHealth
Network published its Value Sets for Digital COVID Certificates in April 2021, these were crossreferenced with the CDC standards to determine common attributes across the three entities, creating
the foundation for the recommendations below.

6.1.3.3 Recommendations
6.1.3.3.1

OVERALL RECOMMENDATIONS

Based on this cross-review process, the GHPC RECOMMENDS that solution providers include thefollowing minimum viable value sets for COVID-19 credentials for global interoperability. Because theGHPC focuses on credentials and passes for both vaccination and testing, these recommendations mostclosely resemble the EU specification. (The EU specification was also informed by WHO’s core dataset,
which originally focused exclusively on vaccination).
Note that GHPC also recommends that CVX code and state/province of vaccination SHOULD be
included as additional data fields for North America only (these two fields are not currently in EU
recommendations).

6.1.3.3.2

HEALTH CERTIFICATES

Verifiable Vaccination Certificates
These guidelines aim at preparing for interoperability between attestations of vaccination for medical
purposes (also known as vaccination certificates). Other purposes of non-discriminatory use (e.g., inparticular for travel purposes) MAY be decided upon by jurisdictional authorities, with attestations ofvaccination reserved for ongoing global legal, ethical, scientific and societal discussions.
COVID-19 Antigen Test Certificate
A common list of COVID-19 rapid antigen tests, including those of which their test results are mutually
recognised, and a common standardized set of data to be included in COVID-19 test result certificates.

6.1.3.3.3 HEALTH CREDENTIALS
Vaccination Credential
Vaccination credentials are to be used primarily as a standardized and interoperable form of proof of
vaccination for medical purposes. For other use cases, such as for the purpose of travel, one could
consider situations where a person arrives in a country and a verifying authority confirms whether the
person has been vaccinated against an infectious disease.
The following data fields SHOULD be included in the vaccination credential:
a. name: surname(s) and forename(s), in that order;
b. date of birth;c. disease or agent targeted;d. vaccine/prophylaxis;
e. vaccine medicinal product;f.

CVX code* (North America only; not currently in EU recommendations);

g. vaccine marketing authorization holder or manufacturer;
h. number in a series of vaccinations/doses;
i.

date of vaccination, indicating the date of the latest dose received;j.

state/province of vaccination* (North America only; not currently in EU recommendations);

k. country of vaccination;

The Good Health Pass Interoperability Blueprint

63

l.

certificate issuer;

m. a unique certificate identifier.
Test Credential
Robust testing strategies have been – and will continue to be – an essential aspect of preparedness andresponse to the COVID-19 pandemic, allowing for early detection of potentially infectious individuals andinsight on infection rates and transmission within communities. They are also a prerequisite to adequate
contact tracing that can help limit the spread through prompt isolation.
The unequal rollout of COVID-19 vaccines underscores the importance of continued, widespread
COVID-19 testing as an essential public health tool – one that must continue alongside vaccination toensure an equitable return to public life. Additionally, with increasing concerns over the circulation of
SARS-CoV-2 variants, testing – and variant-specific testing – will continue to be vital for controlling andsuppressing further spread of the virus.
The following data fields SHOULD be included in the COVID-19 antigen test credential:
a. name: surname(s) and forename(s), in that order;
b. date of birth;c. disease or agent targeted;d. the type of test;
e. test name (optional for NAAT test);f.

test manufacturer (optional for NAAT test);g. date and time of the test sample collection;h. date and time of the test result production (optional for rapid antigen test);i.

result of the test;j.

testing centre or facility;

k. state/province of test* (North America only; not currently in EU recommendations);l.

country of test;

m. certificate issuer;n. a unique certificate identifier.
Recovery Credential
According to current evidence, although still testing positive for SARS-CoV-2, infected individuals who
have recovered from COVID-19 may still be infectious. In those particular cases, negating the virus may
not be viable, with a limited risk of transmission to others.
However, by not presenting a negative test result for unrestricted movement, jurisdictional authorities
would prevent those individuals from crossing borders. On balance, the evidence suggests that those whohave recovered from COVID-19 have a reduced risk of infection.
The following data fields SHOULD be included in the COVID-19 citizen recovery credential:
a. name: surname(s) and forename(s), in that order;
b. date of birth;c. disease or agent the citizen has recovered from;d. date of first positive test result;e. state/province of test* (North America only; not currently in EU recommendations);f.

country of test;

g. certificate issuer;

The Good Health Pass Interoperability Blueprint64

h. certificate valid from;i.

certificate valid until (not more than 180 days after the date of first positive test result);j.

a unique certificate identifier.

6.1.3.3.4 GOOD HEALTH PASSES
While the above health credentials attest that a COVID-19 test event or vaccination event occurred, one
could consider situations where a person may be required to provide proof of COVID-19 status and may
not want – or should not be required to – share all of the information that is captured in a credential.
In these scenarios, such as for international travel, a health pass MAY be used to attest to the minimal
set of data from one or more health records required for a specific verifier or class of verifiers to make aparticular trust decision.
A Good Health Pass SHOULD only include the minimal set of information necessary to verify and confirm
the holder’s vaccination, testing, or recovery status as required for a verifier to make a particular trust
decision. For travel, this SHOULD include the following basic elements:
a. name: surname(s) and forename(s), in that order;
b. date of birth;c. pass status
All defined semantic content MUST be uniquely identified by cryptographic hash functions to ensure thatthe same message always results in the same hash.

6.1.4

Problem #2: Data Exchange – Common Data Model

6.1.4.1 Problem Description
Common data models are used to standardize and facilitate the exchange, sharing, or storing of datafrom multiple sources. They are frequently used in healthcare, where there is a need to share data fromdisparate sources for a particular use, such as clinical research. Common data models can also help
avoid the need to share patient-level data – a privacy preserving feature with great relevance for the Good
Health Pass ecosystem.
Common data models are designed to promote interoperability between systems that encode healthcare
data in different ways. At the same time, there are a multitude of common data models designed forspecific contexts – necessitating thoughtful choices based on the proposed use case.

6.1.4.2 Recommendations
The EU, World Health Organization (WHO), and Vaccine Credentialing Initiative (VCI) have allrecommended FHIR as the common data model of choice for COVID-19 credentialing initiatives. To further
promote interoperability, the GHPC also RECOMMENDS that health credentials and passes SHOULD use
the HL7 FHIR data model as described below. In doing so, credential and pass developers can guaranteethat data elements included will represent the necessary data requirements covering specific jurisdictions
and usage types.
Fast Healthcare Interoperability Resources (FHIR) is a standard for health care data exchange that
ultimately aims to get legacy EHRs (electronic health records) to a point where they can be interoperable.
FHIR allows EHRs the versatility to be used in mobile devices, web-based applications, cloudcommunications, and EHR data-sharing using modular components. This makes it easier for third-party
developers to integrate medical applications into existing systems.

The Good Health Pass Interoperability Blueprint

65

While the FHIR data model aligns Good Health Pass implementers with the data format selected by
the EU/WHO/VCI initiatives, it SHOULD be recognized that FHIR’s adoption is still uneven and there
are many healthcare systems that have not, or could not adopt this data model. To address this, theGHPC RECOMMENDS that solution providers SHOULD provide guidelines and/or tools to convert nonFHIR formatted EHR data into FHIR formatted records as a pre-processing step. Example guidance on
importing csv data into FHIR can be found here.
This RECOMMENDATION assumes that the candidate source EHR data meets the minimum data fieldrequirements called for in the Health Credentials: Vaccination Credential, Test Credential, Recovery
Credential sections above.

6.1.5

Problem #3: Semantic Harmonization

6.1.5.1 Problem Description
In exploring the minimal datasets required to differentiate between certificates, credentials, and passes, it
is clear that COVID-19 related data will often come from disparate, siloed sources.
When data for credentials and passes comes from multiple sources, it can be difficult to facilitate efficient
processing during verification, use an automated rules engine and/or decision support system for passissuance (based on jurisdiction requirements), and support multiple languages. All of these are key
considerations for any proposed solution that would be used to support international travel. Further,
dictionary coding differs across jurisdictions, underscoring the importance of having flexible overlays.
As such, data and semantic harmonization are critical to ensuring interoperability of health credentials
and passes. Data harmonization involves transforming datasets to fit together in a common architecture.
Semantic harmonization is the process of ensuring that – as part of data harmonization – the meaning
and context of data remains uniformly understood by all interacting actors, regardless of how the data
was collected originally. This also means that transient objects such as credentials and passes can be
more easily resolved into multiple languages.

6.1.5.2 Good Health Pass Design Requirements & Considerations
Advances in decentralized data modeling can enable data harmonization across different models andrepresentation formats. The introduction of decentralized technologies in identity, semantics, andgovernance has the added benefit of providing a safeguard against online exploitation, surveillance, or
potential abuse by redistributing digital control away from centralized platforms and placing control backin the hands of a person – a key principle of the GHPC.

6.1.5.3 Recommendations
6.1.5.3.1

OVERALL RECOMMENDATIONSThe GHPC RECOMMENDS using Overlays Capture Architecture (OCA) as a solution for semantic
harmonization between data models and data representation formats that has been specificallydevised for data object interoperability, acting as a catalyst for standardized credential issuance. An
OCA schema stack consists of a stable capture base and interchangeable task-oriented overlays. Thislevel of object separation within the schema introduces a dynamic solution to presenting credentials in
different languages, based on a user’s locale and other language preferences (See Appendix C for more
information).
OCA offers an optimal level of both efficiency and interoperability in alignment with FAIR principles(Findability, Accessibility, Interoperability, and Reusability). The architecture provides a stableinfrastructure to facilitate seamless semantic harmonization and interoperability processes, not only

The Good Health Pass Interoperability Blueprint

66

between internal departments and functions but also between external organizations working under an
ecosystem governance framework (EGF) (e.g., Good Health Pass Ecosystem Governance Framework(GHP EGF)) as defined by an industry collaborative or consortium.
The GHPC is also aware of other semantic architectures being developed in open source communities,
which will be continuously evaluated and may feature in future GHPC publications.

6.1.5.3.2 PROCESSING RECOMMENDATIONSThe GHPC RECOMMENDS using the FHIR-OCA data processing pipeline (see Appendix D). The FHIROCA tool provides for the conversion of COVID-19 vaccination, testing, or recovery JSON formatted
resource bundles via a FHIR JSON-LD context that enables FHIR resource elements to be represented in
JSON-LD. This approach can also include the pre-processing conversion of non-FHIR formatted data into
a processable FHIR format for the FHIR-OCA tool.
This conversion has several advantages, including allowing the FHIR element definitions to be referenced
in a linked data vocabulary, enabling purpose-of-use data framing, and allowing the application of Zero
Knowledge Proof and linked data signature encryption techniques to the health certificate and related
verifiable credentials. Details of this pipeline can be found in Appendix C.

6.1.6

Phased ApproachWith the publication of this document, implementers would take a phased approach toward adoptionof recommended standards. These phases would be defined along timelines measured in 30-, 90-, and180-day segments and further accounted for across industries with different levels of agility based on
established development cycles.
The standards and technology patterns being developed in this specification, and broadly as part of the
GHPC activities, are designed to be used not just for the immediate needs of this phase of the COVID
pandemic but to be a potential framework to handle a variety of verifiable credential use cases that may
arise in the future. To that end, for implementers that require a longer lead time, (e.g., larger companies),
announcements of participation via product road maps, with regular updates until official launch, would
demonstrate their commitment to GHP principles to the community as a whole.

6.1.6.1 Phase One (30 Day Horizon)
1. The GHPC RECOMMENDS that solution providers, issuers and attesters start setting the minimum
viable value sets for COVID-19 credentials required for global interoperability.
2. The GHPC also RECOMMENDS that CVX code and state of vaccination be included as additional
data fields for North America only.
3. To further promote interoperability, the GHPC RECOMMENDS that health credential andpass solution providers/issuers/developers SHOULD start using the HL7 FHIR data model.
For healthcare systems that have not, or could not adopt the FHIR data model, the GHPC
RECOMMENDS that solution providers SHOULD provide guidelines and/or tools to convert nonFHIR formatted EHR data into FHIR formatted records as a pre-processing step.

6.1.6.2 Phase Two (90 Day Horizon)
1. The GHPC RECOMMENDS that solution providers enable semantic harmonization between data
models and data representation formats to create health certificates, health credentials, and GHPs
for jurisdictions they are affiliated with.
2. The GHPC RECOMMENDS using the FHIR-OCA data processing pipeline for the conversion of
COVID-19 vaccination, testing, or recovery JSON formatted resource bundles via a FHIR JSON-LD
context that enables FHIR resource elements to be represented in JSON-LD.

The Good Health Pass Interoperability Blueprint67

3. The GHPC RECOMMENDS that solution providers start testing their health certificates, healthcredentials and GHPs against rules engines for interoperability with other jurisdictions.

6.1.6.3 Phase Three (180 Day Horizon)
The GHPC RECOMMENDS that solution providers work with jurisdictions rolling out health certificates,
health credentials and GHPs.

The Good Health Pass Interoperability Blueprint686.2 Recommendation #5: Credential Formats,
Signatures, and Protocols
6.2.1

Introduction to this Interoperability Challenge

Technical interoperability of digital health passes rests on use of a singular set of formats, digital signature
suites, issuance protocols and presentation protocols.
However, although the promise of digital credentials is enormous, the W3C open standard data model
for cryptographically verifiable digital credentials – widely referred to as verifiable credentials – isonly 18 months old. So there are already many non-W3C verifiable credentials in existence, including
several defined expressly for proof of COVID-19 health status (such as the EU COVID-19 Certificate andthe proposed WHO Digital Documentation of COVID-19 Certificates). Furthermore, even those verifiable
credentials that do follow the W3C standard may use different representation formats and digital
signature types because the W3C specification supports multiple options.
In addition, the W3C standard does not cover any standard protocols for issuance of credentials toholders or presentation of proofs of those credentials to verifiers. It only covers the data model for
representing and signing credentials in a digital format.
So the essence of this interoperability challenge is to specify the precise set of formats, digital signature
suites, issuance protocols, and presentation protocols that will enable maximum interoperability of Good
Health Pass–compliant digital credentials and passes while still meeting the other requirements of the
GHP Interoperability Blueprint.

6.2.2

Objective of this Drafting Group

Based on the goals described above, the objective of this Drafting Group is to specify the following for
GHP-compliant digital health credentials and health passes:
1. The data format(s).
2. The digital signature suite(s).
3. The issuance protocol(s).
4. The presentation protocol(s).
Ideally, only one choice should be recommended for each of these. The reason, in the words of Brian
Behlendorf, General Manager of Blockchain, Healthcare, and Identity at the Linux Foundation, is that
“Optionality is never free – it comes at the cost of combinatorial complexity for all implementers.” This
cost is redoubled when security and privacy considerations are paramount.
There are many other considerations that go into making these choices, including:z Performance requirements at airports, airlines, and for other travel industry verifiers where reducing
travel friction is of critical importance,z Offline verification requirements in some locales (e.g., no Internet, loss of power, etc.),z Meeting regulatory requirements for security and privacy,z Ease of integration with existing systems and solutions, especially legacy travel reservation,
security, and check-in systems and procedures andz Cost and availability.

The Good Health Pass Interoperability Blueprint69

6.2.3 Problem #1: Specify how GHP-compliant credential
systems can interoperate with non-GHP credential
systems
6.2.3.1 Problem Description
As explained in the Background section, there are many different systems and processes for issuing
digitally-signed health data. The GHP ecosystem needs to be able to accept certificates and credentials
from issuers who are not following our recommended standards for verifiable credentials.
Figure 8 illustrates conceptually how other non-GHP certificate and credential systems – whether or
not they are compatible with the W3C standard – should be accepted as inputs used to produce a GHPcompliant health pass.

Figure 8: Health certificates and credentials that are not GHP-compliant can all be
used as inputs to generate a GHP-compliant health pass (or travel pass)

6.2.3.2 Good Health Pass Design Requirements & Considerations
Good Health Pass architecture is explicitly designed to accommodate other inputs of verifiable healthdata. The primary design consideration is that issuers of GHP-compliant health credentials and passes
who wish to ingest other health credential formats need to integrate the necessary verification services –sometimes called “universal verifiers”. These issuers will also typically need to implement a rules engine
and/or decision support system to apply the necessary verification and re-issuance rules.
In addition, non-GHP certificates or credentials might not use W3C Decentralized Identifiers (DIDs)
or the digital signature suites recommended in this document. For example, both the WHO Digital
Documentation of COVID-19 Certificate and the EU Digital COVID Certificate plan to use public key
directories (PKDs) based on conventional X.509 PKI public key certificates. This contingency has beenrecognized by the GHP Trust Registries group. See Recommendation #8 for their proposals, which
envisage a global trust registry network using an open standard protocol supporting both DID-based andX.509-based public key verification.

The Good Health Pass Interoperability Blueprint70

A universal verifier MAY also need to accept other credential presentation protocols besides thoserecommended in this document. Of particular interest is the OpenID Connect (OIDC) protocol andspecifically the Self-Issued OpenID Provider (SIOP) protocol under development at the OpenID
Foundation in collaboration with the Decentralized Identity Foundation. This is an active, ongoing effort
to define how the OIDC protocol can be used for the issuance and presentation of W3C Verifiable
Credentials.
Furthermore, OIDC and OAuth2 can already be leveraged in the issuance process by providing anauthentication solution for consumers to access their health records in an electronic medical record(EMR) or similar system using the HL7 Fast Healthcare Interoperability Resources (FHIR) standard asshown in Figure 9.8

Figure 9: Holder authentication to a FHIR-enabled health record systemusing OAuth 2 and OIDC

6.2.3.3 Recommendations
1. Issuers of GHP-compliant digital credentials and passes in the travel domain SHOULD also serve as
verifiers accepting non-GHP-compliant health credentials.
2. Issuers who choose to serve as verifiers of non-GHP credentials MUST follow the GHP
Interoperability Blueprint recommendations for GHP-compliant verifiers.
3. The Good Health Pass digital trust ecosystem SHOULD support the development of open source
universal verifier code for processing and verification of these non-GHP credentials. (Somecompanies have already developed such code.)

6.2.4 Problem #2: Determine the precise open standards
necessary for interoperability of GHP-compliant digitalcredentials
6.2.4.1 Problem Description
As described above, interoperability requires that we make specific choices among the myriad of formats,signatures, and exchange protocols in use. Our interoperability recommendations will address these in thefollowing categories:
z W3C Verifiable Credential formats and signatures,

8

https://arxiv.org/ftp/arxiv/papers/2103/2103.04142.pdf

The Good Health Pass Interoperability Blueprint71

z W3C Verifiable Credential issuance protocol, andz W3C Verifiable Credential presentation protocol.

6.2.4.2 Good Health Pass Design Requirements & Considerations
For maximum interoperability, GHP-compliant digital credentials should be designed whenever possible
to use:1. A single format compliant with the W3C Verifiable Credentials standard.
2. A single digital signature suite that meets GHP security and privacy requirements.
3. A single protocol for issuance (issuer-to-holder) and presentation (holder-to-verifier).
Other key considerations in arriving at our recommendations include:z User control:GHP-compliant digital wallet apps need to provide the holder with maximum control
of how and when the credentials are shared.
z Privacy:GHP-compliant solutions SHOULD not “phone home” or implement other designs orfeatures that allow for tracking or surveillance. They SHOULD also apply data minimization via
selective disclosure. And they SHOULD minimize correlation risks.

What is the “phone home” problem?
Digital identity systems built for enterprise Identity and Access Management (IAM) and federation
operate using an architectural pattern often referred to as “phoning home”. When individuals
enroll in a federated identity system (usually through an entity called an identity provider or IdP),
they are assigned an identifier and register one or more ways to authenticate (prove) they arein control of this identifier, such as an ordinary password, one-time password (OTP) token, or abiometric that is enrolled and matched against. If, in the process of authenticating with someother entity within that federated identity system, the enrolled individual is redirected back to theentity that issued the original identifier, that is called “phoning home”. This is a privacy problem
within all federated identity systems because it allows the IdP to track the individual’s activity
within the network. For example, in a government context, it creates a way for governments totrack usage of citizens within the system.

These design considerations make it clear that a GHP-compliant health credential format SHOULD
ideally use a zero-knowledge proof (ZKP) cryptography because its ability to support selective disclosuremeans the holder can produce any number of context-specific GHP-compliant health passes that meetthe requirements of a specific verifier at a specific point in time. This is illustrated in Figure 10 withan example of a verifier making a request from a traveler’s GHP-compliant digital wallet app to share
the precise set of health credential and travel document credential data needed use BBS+ ZKP digital
signatures.

The Good Health Pass Interoperability Blueprint

72

Figure 10: A zero-knowledge proof credential can support dynamic
generation of any number of context-specific GHP-compliant passes

6.2.4.3 Recommendations
6.2.4.3.1 OVERALL RECOMMENDATIONS
Implementers MUST implement the following open standards according to the timelines specified below:
1. JSON-LD formatted W3C Verifiable Credentials
2. BBS+ LD-Signatures
3. WACI PEx Protocols for issuance and verification as defined by the DIF Claims and Credentials
WG.

IMPORTANT: We recognize that we are recommending a protocol that is still a work-in-progress,
but we do so for a specific reason: each of the current options on the market were designed withdifferent architectural assumptions and do not yet have broad adoption. The emergence in thelast year of a W3C Verifiable Credentials conformat “flavor” JSON-LD ZKP with BBS+ signatures
as a common format and signature suite represents an inflection point. Developers of several
different previous irreconcilable VC technology stacks (JSON-LD and ZKP-CL) are willing to adopt
it. This has spurred the Good Health Pass community and other stakeholders to converge first on
a presentation protocol and secondly on an issuance protocol that will work across these different
technology stacks. With convergence around this VC format what was missing was a common
protocol exchange format between to clusters of interoperability the SVIP program cohorts andthe Aires Community. The work on Wallet and Credential Interaction- Presentation Exchange(WACI-PEx) emerges from leaders in these two communities and draws on DIDComm, Aries Proof
Request, Aries Credential Issuance, DIF Presentation Exchange, WACI (Wallet and Agent Credential
Interaction), and VC-HTTP-API. Because this emerging protocol is merging the best and simplest
elements of these together, this is what we are recommending.
While other existing approaches do exist, such as X.509, this approach was selected in order tosupport zero-knowledge proofs (ZKPs) and selective disclosure. This approach allows for thepresentation of individually signed attributes, thereby reducing the amount of PII/PHI that averifying organization may need to receive. Please see sections 6.3 and 7.2 for further information
on how other technologies are leveraged or interact with this approach.
4. If a GHP-compliant digital wallet app or rules engine/DSS supports sharing digital health

The Good Health Pass Interoperability Blueprint73

credentials in other formats, the app or rules engine/DSS MUST display an explicit warning
to the holder about the privacy implications if a verifier requests a presentation of an entire
credential – thus requiring the holder to share all the data – instead of presenting (or asking a rules
engine/DSS to generate) a privacy-preserving GHP-compliant health pass.

6.2.4.3.2 PHASE ONE (30 DAY HORIZON)
Purpose: To converge on a common data model.
1. MUST publicly document your existing credential formats, signatures, and exchange protocols.
2. SHOULD use W3C Verifiable Credentials which leverage the JSON-LD format and BBS+ signaturescheme.
3. SHOULD have a transition plan in place (for existing implementers) or begin building toward (fornew implementers) to comply with the recommendations in this document.
4. If possible within 30 days, implementers SHOULD use W3C Verifiable Credentials as follows:
4.1. Formats and Signatures: JSON-LD, with BBS+
4.2. Issuance Protocol:
4.2.1. Existing implementers with an existing issuance protocol: adapt that protocol asneeded to work with JSON-LD with BBS+ credentials
4.2.2. New implementers: implement support for EITHER Aries Issuance Protocol OR CCG
Issuance Protocol
4.3. Presentation Protocol: WACI Pe-X for presentation

6.2.4.3.3 PHASE TWO (90 DAY HORIZON)
Purpose: To enable interoperable presentation of GHP-compliant credentials. That means regardlessof which credentials were issued, to which kinds of digital wallets, those credentials will be able to bepresented to any verifier.
MUST have transition plan in place for moving to the recommended formats, signatures, and exchange
protocols
SHOULD use W3C Verifiable Credentials as follows:z Formats and Signatures:JSON-LD, with BBS+z Presentation Protocol:WACI Pe-X for presentation
If implementers are able to within 90 days, they SHOULD use W3C Verifiable Credentials as follows:z Issuance Protocol:WACI Pe-X for issuance

6.2.4.3.4 PHASE THREE (180 DAY HORIZON)
Purpose: To enable interoperable issuance and presentation of GHP-compliant credentials using the, now
formalized, Wallet and Credentials Interactions (WACI) Presentation Exchange (Pe-X) protocols. Thatmeans regardless of which digital wallet an individual possesses, credentials from any GHP-compliant
issuer can be issued to that wallet and accepted by the individual. This prevents user experiencechallenges associated with downloading multiple apps (e.g., imagine needing to download app A to travel
to a country and download app B to travel home) and enables user choice of wallet.
MUST use W3C Verifiable Credentials as follows:z Formats and Signatures:JSON-LD, with BBS+z Issuance Protocol:WACI Pe-X for issuancez Presentation Protocol:WACI Pe-X for presentation

The Good Health Pass Interoperability Blueprint74

6.2.5

Problem #3: Determine the precise open standards
necessary for interoperability of GHP-compliant
digital passes

6.2.5.1 Problem Description
A GHP-compliant digital pass is simply a GHP-compliant digital credential to which data minimization
and anti-correlation have been applied for privacy-preservation as illustrated in Figure 1. Therefore theinteroperability requirements in this section overlap with those of Problem #2.

6.2.5.2 Good Health Pass Design Requirements & Considerations
Our JSON-LD / BBS+ recommendation for a GHP-compliant health credential in the previous section
will automatically produce a GHP-compliant health pass in response to a GHP-compliant verifiable
presentation request from a verifier.
However, what if a holder either has a non-GHP-compliant digital wallet – or does not have a digital device
at all? In this case the holder is not capable of accepting a BBS+ credential since it requires a digitalinteraction with the holder. So we provide a second recommendation for non-ZKP health credentials.
Since such a credential is static and does not support selective disclosure, it must be shared as a whole,either in a simple digital format (such as a QR code displayed by a simple digital wallet or mobile web app)or printed on paper.
Figure 11 illustrates the same verifier scenario as Figure 10 except the holder’s credentials are in a nonZKP format using standard Ed25519 digital signatures. In this case, the holder’s only choice is to share thefull credentials containing the attributes the verifier requires.

Figure 11: When an issuer or holder cannot support BBS+ credentials, a
static Ed25519 credential can be used (either digital or paper),but it does not support selective disclosure

The Good Health Pass Interoperability Blueprint75

6.2.5.3 Recommendations
6.2.5.3.1 OVERALL RECOMMENDATIONS
1. For dynamic GHP-compliant health passes, the recommendations in Problem #2 apply.
2. For static GHP-compliant health passes, an implementer MUST implement JSON-LD formatted
W3C Verifiable Credentials with ED25519 signatures and using the same issuance and presentation
protocols as in Problem #2.

6.2.5.3.2 PHASE ONE (30 DAY HORIZON)MUST publicly document your existing credential formats, signatures, and exchange protocols.
SHOULD have transition plan in place for moving to the recommended formats, signatures, and exchange
protocols.
SHOULD use W3C Verifiable Credentials where:
1. Formats and Signaturesare: JSON-LD, with either BBS+ (for passes derived from GHP-compliant
credentials) or ED25519 signatures (for passes directly issued)
2. Issuance Protocolis: WACI Pe-X
3. Presentation Protocolis: WACI Pe-X

6.2.5.3.3 PHASE TWO (90 DAY HORIZON)MUST have transition plan in place for moving to the recommended formats, signatures, and exchange
protocols.
SHOULD use W3C Verifiable Credentials where:
1. Formats and Signaturesare: JSON-LD, with either BBS+ (for passes derived from GHP-compliant
credentials) or ED25519 signatures (for passes directly issued)
2. Issuance Protocolis: WACI Pe-X
3. Presentation Protocolis: WACI Pe-X

6.2.5.3.4 PHASE THREE (180 DAY HORIZON)MUST use W3C Verifiable Credentials where:
1. Formats and Signaturesare: JSON-LD, with either BBS+ (for passes derived from GHP-compliant
credentials) or ED25519 signatures (for passes directly issued)
2. Issuance Protocolis: WACI Pe-X
3. Presentation Protocolis: WACI Pe-X

6.2.6

Problem #4: Agree on implementation requirements forsecurity, privacy, and data protection of GHP-compliant
digital credentials and passes

6.2.6.1 Problem Description
Digital credentials, especially digital health credentials, contain sensitive personal information that
requires continuous safeguards to prevent unauthorized or unintentional disclosure. The prospective
credential ecosystem for health passes means that credentials MUST be supported by a comprehensive
trust assurance framework that not only supports all jurisdictional compliance requirements for security
and privacy, but incorporates open standards, accepted cryptographic methods, and internationally

The Good Health Pass Interoperability Blueprint76

recognized security processes to minimize risk to the credential holder. General security, privacy, and dataprotection guidance is provided in Recommendation #2 – Security, Privacy, and Data Protection; here wewill focus on corresponding characteristics specific to Formats, Protocols, and Signatures.

6.2.6.2 Good Health Pass Design Requirements & Considerations
The world has a very large patchwork of different security and data protection requirements, some ofwhich are regional in nature. As this blueprint is intended to be usable worldwide, it does not require
specific approaches, but instead directs policy makers and practitioners to appropriate standards withsome supplemental direction in terms of desired outcome objectives.

6.2.6.3 Recommendations
6.2.6.3.1 OVERALL RECOMMENDATIONS
Digital credential issuers and verifiers MUST demonstrate adherence to all jurisdictional security andprivacy requirements, and provide evidence of their implementation of recognized standards and bestpractices in information security and privacy, such as ISO 2700X, ISO 29100, ENISA, HIPAA, NIST CSF, or
Canadian ITSG-33, as examples.
All credential issuers and verifiers MUST possess certifications or independent party assessment
documentation that demonstrates compliance with an internationally recognized cybersecurity standard.

6.2.6.3.2 PHASE ONE (30 DAY HORIZON)
1. Current and prospective issuers and verifiers MUST conform to the GHP ecosystem governanceframework requirements for certification with supported evidence.
2. GHP-compliant passes SHOULD apply data minimization and anti-correlation regardless of what
technology is used. Please refer to the other recommendations in this section as well as the
security, privacy, and data protection recommendations for more detail.

6.2.6.3.3 PHASE TWO (90 DAY HORIZON)
1. Current and prospective issuers SHOULD have a self-assessment, risk assessment, and plan ofaction and milestones (POA&M) to demonstrate the intended path for compliance and certification.
2. GHP-compliant passes SHOULD support selective disclosure and non-correlating signatures byfollowing the recommendations in Problem #2 and Problem #3.

6.2.6.3.4 PHASE THREE (180 DAY HORIZON)
1. Issuers MUST have a self-assessment, risk assessment, and Plan of Action and Milestones(POA&M) to demonstrate the intended path for compliance and certification.
2. GHP-compliant passes MUST support selective disclosure, non-correlating signatures, and noncorrelating holder binding.

6.2.7

Problem #5: Specify how GHP-compliant implementations
can support offline usage of digital credentials and passes

6.2.7.1 Problem Description
There are a number of different circumstances under which digital credentials and passes may be used.
While some of these circumstances allow for the use of the Internet for actions such as connecting totrust registries, verifying public keys, etc., this is not always the case. For example, many border crossings
do not allow Internet access for either the holder or the verifier.

The Good Health Pass Interoperability Blueprint

77

GHP-compliant implementations need to work in environments that do not allow Internet access. Thisaffects both holders and verifiers.

6.2.7.2 Good Health Pass Design Requirements & Considerations
This section identifies key areas where system providers need to pay special attention to the challenge ofoffline usage, and where providers will need to architect appropriately. For example, offline use requires
trust registries to support the caching of data needed for verification.

6.2.7.3 Recommendations
6.2.7.3.1

OVERALL RECOMMENDATIONS

1. A mechanism MUST exist whereby holders can present credentials and passes without the supportof the Internet.
2. A mechanism MUST exist whereby verifiers can verify the validity of the presented credentials andpasses without the support of the Internet. It is recognized that this means verifiers MAY be using
outdated information to perform this task.
3. A mechanism MUST exist whereby holders can present credentials and passes to the verifier
without the support of the Internet. This process MAY include the request from the verifier to theholder.

6.2.7.3.2

PHASE ONE (30 DAY HORIZON)The solution SHOULD support offline use with W3C Verifiable Credentials.

6.2.7.3.3

PHASE TWO (90 DAY HORIZON)The solution MUST support offline use with W3C Verifiable Credentials. It SHOULD support offline usewith privacy-preserving capability.

6.2.7.3.4

PHASE THREE (180 DAY HORIZON)The solution MUST support offline use with W3C Verifiable Credentials and privacy-preserving capability.

6.2.8 Problem #6: Determine the formats and signatures forthe payload of GHP-compliant paper credentials
and passes
6.2.8.1 Problem Description
The previous problem statements have applied to digital credentials and passes, where the assumption isthat the credential or pass is issued directly to the holder’s digital wallet and then presented to a verifier,when needed, in the same all-digital manner.
However for purposes of equity and inclusion, GHP-compliant health credentials and passes also needto support being transmitted in a non-digital version that does not require a digital device or an Internet
connection. We call this a paper credential or paper pass because it is physically printed in somemanner, but the underlying medium can be any non-digital medium capable of carrying information (e.g.,plastic, metal, or cloth).

6.2.8.2 Good Health Pass Design Requirements & Considerations
Once a paper pass is scanned by a digital scanning device of some kind, it is converted back into a digital
representation. At that point it would be ideal for this representation – or an algorithmic transformation ofit – to be directly processable according to the previous recommendations in this document.

The Good Health Pass Interoperability Blueprint

78

However there is a specific challenge in the case where the paper pass has been produced directly by
an issuer without the holder having a digital wallet. In this case, the pass cannot be digitally signed by a
BBS+ signature because the holder has no mechanism for generating and sharing the BLS private key
or link secret needed by the issuer to issue a JSON-LD with BBS+ credential. This is why problem #3
recommends issuing a static GHP-compliant digital pass that still uses the JSON-LD format but with theEd25519 digital signature suite. This format can be printed directly as a static paper pass.

6.2.8.3 Recommendations
1. The output of scanning a GHP-compliant paper credential or paper pass MUST be a digital
representation that is either directly conformant with or or is algorithmically transformable into oneof the digital credential representation formats recommended in this document.
2. In the case that the holder is not capable of supporting the recommended BBS+ digital signature
type, the issuer MUST digitally sign the paper credential or pass with a linked data signature using
the Ed25519Signature2020 signature suite.
3. The 30, 90, and 180 day phased recommendations SHOULD follow the recommendations of thePaper Credentials group (see Recommendation #6).

6.2.9 Problem #7: Determine a two-way transformation
between the paper versions and the digital versions of
GHP-compliant credentials and passes
6.2.9.1 Problem Description
The preceding problem described how a paper credential or pass can be converted into a digital
representation conformant with the recommendations in this document for purposes of verification. But
it would be ideal for holders to be able to complete a full two-way “round-trip” from digital credentials andpasses into their paper versions and back again.

6.2.9.2 Good Health Pass Design Requirements & Considerations
We have already recommended the overall process for transforming from a digital format into a paper
format. The precise algorithm to follow to produce a print document containing a QR code will be arecommendation from the Paper Credentials group (see Recommendation #6).
The remaining challenge is to transform from the paper version back into the digital version such thatthe credential or pass can be stored in the holder’s digital wallet and used in the same manner as if it had
been issued directly into the holder’s digital wallet app.

6.2.9.3 Recommendations
6.2.9.3.1 OVERALL RECOMMENDATIONSThere are two types of digital health information described here that can be transformed into a paper
version: GHP-compliant digital credentials, and GHP-compliant digital passes. Paper versions of these
MAY be produced, but they have different qualities and intended uses. The algorithm by which thistransformation is performed is specified in Recommendation #6 – Paper Credentials.

6.2.9.3.2 GHP-COMPLIANT DIGITAL AND PAPER PASSES
A paper version of a GHP-compliant digital pass is intended to be shared with a verifier, just as a digitalpass would be. All of the recommendations around data minimization and context-specific production
apply here.

The Good Health Pass Interoperability Blueprint79

1. A GHP-compliant digital pass MAY be converted into a GHP paper pass.
2. The resulting GHP-compliant paper pass MAY be converted back into a GHP-compliant digital pass.
3. An Issuer MAY directly issue a GHP-compliant paper pass to a holder.
4. If conversion between paper and digital passes is supported, it MUST be lossless (i.e. the artifactthat exists as a GHP-compliant digital pass MUST be indistinguishable from the result of convertingthat GHP-compliant digital pass into a GHP-compliant paper pass and back again).

6.2.9.3.3 GHP-COMPLIANT DIGITAL AND PAPER CREDENTIALS
A paper version of a GHP-compliant digital credential is not intended to be shared with a verifier in thetravel domain because it contains a full set of health and other personal attributes. Additionally, since it
contains the issuer’s BBS+ signature for the holder (which requires input from the verifier to whom thesignature will be presented), a different verifier would not have the information needed to verify it.
Instead, a paper version of a GHP-compliant digital credential is intended to provide a means of storing
the credential until it may be converted back into digital form. This is necessary before the GHP-compliant
paper credential can be used by the holder.
1. A GHP-compliant digital credential MAY be converted into a GHP-compliant paper credential.
2. A GHP-compliant paper credential converted from a GHP-compliant digital credential MAY be
converted back into a GHP-compliant digital credential.
3. If such transformation between paper and digital credentials is supported, it MUST be lossless (i.e.
the artifact that exists as a GHP-compliant digital credential MUST be indistinguishable from theresult of converting that GHP-compliant digital credential into a GHP-compliant paper credential
and back again).
4. If a holder is not able to accept a GHP-compliant digital credential or pass, rather than issue a GHPcompliant paper credential to a holder, it is RECOMMENDED to issue a GHP-compliant paper passto the holder.
4.1. It is RECOMMENDED to apply as much data minimization and anti-correlation as possible tostill meet the holder’s and verifier’s requirements.

6.2.10 Interoperability Testing Guidance
Good Health Pass-complaint credential testing suites SHOULD be created based on W3C Verifiable
Credential JSON-LD, ZKP with BBS+ signature format and the WACI Pe-X issuance and presentation
protocols. Test suites already exist for Hyperledger Aries (the open source project often used as thewallet/agent component for the issuance, verification, and sharing of W3C Verifiable Credentials) and theopen source Verifiable Credentials test suite hosted by W3C CCG originally developed for the U.S. DHS
S&T Silicon Valley Innovation Program.
1. Within Phase 1 (30 days), we recommend producing an analysis of the existing test suites to identify
the gaps and formulate a plan and resources for addressing them.
1.1. The test harness MUST test both issuer to holder systems and holder to verifier systems.
2. Within Phase 2 (90 days), we recommend:
2.1. Completing the work for the test suites to test the requirements of the Good Health Pass
Interoperability Blueprint.
2.2. Commencing NxN matrix testing of implementations seeking GHP-compliance.
3. Within Phase 3 (180 days), we recommend:
3.1. Development and execution of a GHP-compliant certification program and trust mark.

The Good Health Pass Interoperability Blueprint80

6.3 Recommendation #6: Offline Paper Credentials
6.3.1

Introduction to this Interoperability Challenge

A fundamental principle of the Good Health Pass Collaborative (GHPC) is that health pass solutions must
serve everyone, including those who may be socially, financially, digitally, or otherwise excluded, and thosethat do not have guaranteed connectivity or a high degree of digital infrastructure. Additionally, not all
people have smartphones, the physical ability to use them, or the desire to use them for this purpose. For
these reasons, a good health pass ecosystem must also consider the use of offline paper credentials.
However, offline paper credentials cannot support privacy-preserving selective disclosure and zeroknowledge presentation requests and proof exchanges: the entire credential is presented as a wholeto the verifier with its cryptographic signature, and it is impossible to present only a subset of theinformation. The QR code and personal data contained therein, once scanned, serves as a permanent
globally unique identifier for the data subject and the transmitted data set. This means paper credentials
can present risks to individual privacy and are not the preferred approach for transmitting personal healthdata.
The trade-offs and compromises of offline paper credentials must be balanced alongside considerations
around ease of use, equity, and time to implement. The massive scale and importance of providing
COVID-19 status underscores the need for digital means to streamline this process – which necessitates
an upgrade from unverifiable paper evidence of health status to verifiable paper evidence.

6.3.2

GHP Design Considerations and Constraints

There are two key design considerations that underpin the recommendations made in this section: 1) A
good health pass must provide a way for people to prove COVID-19 health status without requiring thatthey have a smartphone and active connectivity; and 2) A good health pass ecosystem must provide away for verifiers to receive, verify, and process a person’s COVID-19 health status using systems that
operate offline from internet connectivity, meaning they cannot connect back to issuers or other actors.
There are proposed approaches to address the privacy concerns around the paper credential requirement
outlined above, such as storing the credential in a “cloud wallet” and only including the URL in the QR
code (i.e., a “digital twin” approach). However, this doesn’t address the offline design consideration andrequires significant infrastructure to stand-up.
There are two uses of paper verifiable credentials. The first is to share without having or exposing anelectronic device. This is the case for holders that might not be technologically savvy, do not trust thestability of their devices, or want to avoid the hassle or anxiety of having a powered device ready forscanning when needed.
The second is to store for longer periods of time. Since vaccine records are ideally saved for a lifetime andconsumer electronic devices (e.g., phones, laptops, etc) need to be replaced frequently, the use of paper
still creates an equitable and convenient way to store records, either as a primary source or as a backup
from an electronic device.
In the same way people boarding an airplane may still use paper tickets, and students still receive theirgraduation certificates on paper – even when there are electronic options available – paper credentials
continue to create a peace of mind that is not yet found in electronic records.
By virtue of being paper-based, some aspects of a paper credential’s user experience (UX) will be notably
different from its smartphone-based equivalent. Where possible, though, we desire a unified experience

The Good Health Pass Interoperability Blueprint81

so people can broadly use the same approaches and rely on the same mental models no matter if a healthcredential or pass is on a smartphone or on paper.

6.3.3

Background

Before COVID-19, proofs of vaccination tended to be paper-based and “low assurance”; this also tended
to matter less because people rarely needed to prove this information, and the risk or incidence of fraud
was relatively small or at least not broadly known or considered. For example, in international travel, paper
vaccination cards such as the WHO Yellow Card are used where proof of immunization is required.
Today, the scale and importance of proving COVID-19 status requires improvements to data privacy, data
integrity, and confidentiality in disclosure. Digital systems include safeguards that have evolved in order tosupport system integrity and trust. These include avoiding persistent and global identifiers, using
short-lived pairwise and session-based identifiers, preventing replay of a transaction, using good
cryptography, data minimization, selective disclosure, zero-knowledge proofs, and guarding against abusefrom an actor-in-the-middle of a transaction flow.
Although the world is already set up to support paper-based solutions, many of the above safeguards
cannot be implemented in paper-based designs. Additionally, paper-based implementations have different
design constraints than digital implementations – which become particularly pronounced at scale. For
example, paper-based solutions:z are statically printed and cannot directly implement time-limited, session-specific, dynamic data
features that aid in privacy, security and integrity;z must include, in verification situations without supporting documents or connectivity, all of the dataand personal information that may be needed, introducing the potential challenges of global unique
identifiers, data spills, and uncontrolled replays;z may be altered or faked, and cannot match smartphone security and biometrics;z may be stored by someone for a long time with data that does not change, rather than digitally
deleted and re-issued as needed;z may be able to be presented multiple times, rather than being restricted to a single use;z may not be as easy to revoke if issued in error, if the data changes or situations of use change;z are not easily bound to the person that holds them, unlike online solutions that can use digitalsigning and cryptography to prove the intended holder.
As such, the recommendations in this document are the result of collaboration between manyorganizations with expertise in QR codes, encryption, compression, W3C VCs, and W3C DIDs to develop
carefully considered compensating mechanisms that are associated with the paper printable QR code
option, including severely restricted personal information and data elements.
Note that in this document we talk specifically about using QR codes for paper credentials, but the sameideas and recommendations work for any other machine-readable code. Additionally, when we use theterm “paper credential” throughout, we mean a paper-based verifiable credential.

6.3.4

Objective of this Drafting GroupTo explore the unique challenges presented by paper credentials and make recommendations as to
how they can be supported in a way consistent with the overall principles of the Good Health Pass
Collaborative, including privacy and security. Since paper credentials experience the same interoperability
challenges of digital credentials, albeit with unique constraints, we chose to break down our investigation
into the same set of challenges. We have also attempted, wherever possible, to minimize divergence

The Good Health Pass Interoperability Blueprint82

between digital and paper strategies, and make recommendations for a more cohesive implementation
strategy – allowing paper credentials to participate in the digital ecosystem and vice-versa.

6.3.5

Problem #1: Consistent User Experience

6.3.5.1 Problem Description
Paper credentials, and passes, present a unique set of challenges that impact credentialing, presentation,and verification, which if not carefully considered could result in a divergence in the benefits, protections,and user experiences of those holding paper compared to those holding digital.
This will add complexity for organizations implementing credential-driven business processes and raise
the barrier to adoption. It will also add complexity for those individuals holding paper credentials, not leastof all because it is reasonable to assume that individuals will migrate from physical to digital over time,and could hold a combination of physical and digital at any point in time, particularly in the case ofmulti-generational households. It is also reasonable to assume that holders of a paper credential may
need to present online as well as in-person, such as requesting a boarding pass, and therefore needflexibility for how they can use their paper credential.
The main user experience challenges with paper credentials or passes relate to:
1. The method by which the Issuer issues the credential to the holder; including layout, privacy
protections, techniques to reduce the risk of fraud, and minimum requirements for QR codes.
2. The method by which the holder presents the credential to the verifier; including in-person, online.
3. The method by which the verifier verifies the credential; scanning technology and verification
process.
If we want to create a consistent user experience for holders of paper credentials, we need to makerecommendations that will address these challenges.
We have focused on general considerations that are specific to paper credentials. We have not considered
the broader user stories that are already described in the Recommendation #1: Consistent User
Experience, as these are broadly applicable to both digital and paper credentials. No conflicts have been
observed between our two sets of recommendations.

6.3.5.2 Good Health Pass Design Requirements & Considerations
An optimal implementation needs to take the following into consideration:
1. The format of a paper pass or credential for machine scanning and human readability.
2. Constraints in the techniques by which paper credentials can be scanned; specifically to address
legacy scanning devices, older phones, and other constraints on QR code size, compression andencodings.
3. Interoperability between paper and digital credentials and passes, where individuals may want tomigrate from one to the other.
4. Hashing, signing algorithms need to be secure but make small outputs (ee recommendation on
ED25519 in Section 6.2.5.3.1)
5. Data fields need to respect global languages and names
6. Spec must be implementable on low-powered hardware
7. Support as many programming environments as possible
8. Fully offline operation has to work – online maybe once a week at most

The Good Health Pass Interoperability Blueprint

83

The decision to use QR codes was made because:z QR codes can store more data, both in terms of number of “bits on paper” and in terms of efficiencyof recording non-ASCII data. PDF 417’s smaller ASCII-based encoding is likely not capable ofencoding the size and types of payloads we expect;z QR codes have consumer recognizability compared to other encoding formats; andz QR codes are well supported by well-tested production-deployed libraries in popular programming
languages.
Unlike a digital credential where the holder has options to choose what data to disclose at presentation
time, with a paper credential the selective disclosure options need to be set up when the credential isissued. Selective disclosure can be implemented through a card design that can include multiple QR
codes. For example; by providing multiple QR codes, each with different levels of disclosure. With multiple
options, an educated user can choose what to share by presenting the QR code with the most appropriate
information set for the occasion.

6.3.5.3 Recommendations
6.3.5.3.1 FORMAT OF A GOOD HEALTH PASS
A GHP-compliant paper credential or Good Health Pass:
1. MUST allow individuals who do not have a smartphone or do not want to hold a digital credential
to participate in business processes that require proof of COVID status. NB: “Paper” stands for any
physically-printed, non-electronic medium (e.g., plastic).
2. MUST use QR codes, to provide a simple and broadly used mechanism for exchanging credentialdata.
3. MUST format the QR code message as a URI.
4. SHOULD display all fields found in the QR code legibly on the paper credential/pass, so that theperson can see exactly what is stored in the machine readable QR code.

6.3.5.3.2 ISSUANCE OF A GHP-COMPLIANT PAPER CREDENTIAL OR GOOD HEALTH PASS
A GHP-compliant paper credential or Good Health Pass:
1. MUST offer selective disclosure options when issuing/printing out, to ensure that the person
only needs to share the minimum amount of information for a specific business process; such as
retrieving your boarding pass.
2. MUST include, in the QR code, all information needed to cryptographically verify the credential andperform the use case, to support an offline use case where there may not be Internet access at the
point of credential exchange.
3. MUST provide the holder with clear guidelines on how they can recover their credential, if recovery
is available.
4. MUST provide the holder with a clear description of what happens when they present theircredential to a verifier.
5. MUST provide the holder with information about their rights as it relates to the credential being
issued to them.
6. MUST provide the holder with clear guidelines on how they can keep their information secure andprivate.

6.3.5.3.3 PRESENTATION OF A GOOD HEALTH PASS
See “Recommendation #5: Credential Formats, Signatures, and Protocols” for the recommended QR codetechnical specifications.

The Good Health Pass Interoperability Blueprint84

1. MUST ensure the QR code is machine readable when printed from or displayed on low-end devices.
2. MUST support a number of different QR code scanning options to address legacy devices, older
phones, and other constraints on size, CPU performance (when using compression), and encoding.
3. MUST specify the expected QR code reading distance, where some QRs are made to be displayed inlarge displays to be read at a distance, others in small form-factors to be read at close distance.
4. SHOULD support decode and verification directly in low-end QR scanning devices.

6.3.5.3.4 VERIFICATION OF A GHP-COMPLIANT PAPER CREDENTIAL OR GOOD
HEALTH PASS
1. MUST collect electronic consent from the holder if personal data is being harvested from the QR
code being presented.
2. MUST provide means to download and cache all needed information to cryptographically verify thecredential so that verification can happen offline.
3. MAY collect electronic consent from the holder when verifying a credential.

6.3.5.3.5 PARTICIPATION IN ONLINE PROCESSES
1. MUST be able to participate in a digital transaction, such as an online check-in system.
2. SHOULD be able to be converted into a digital credential, so that a person who has received a paper
credential can choose to migrate to digital. It would be optimal if paper credentials could be a paperbased version of their digital cousin, but that may not always be the case due to various constraints,
such as QR code size or selective disclosure constraints. For example, paper credentials MAY need
to apply minimization or compression techniques that do not easily facilitate backward mapping totheir digital alternative.
3. SHOULD be able to be generated from a digital credential, so that a person who has received adigital credential can choose to convert into a paper credential so they can use it through more
traditional paper-based QR code scanning

6.3.6

Problem #2: Standard Data Models and Elements

6.3.6.1 Problem Description
Paper credentials cannot participate in privacy-preserving presentation requests and proof exchanges:
whatever is in the credential is presented as a whole to the verifier. By contrast, a presentation requestfrom a digital credential is able to selectively request information or a Zero Knowledge Proof from thecredential. For example, only asking for the first and last name from a driver’s license, or a proof that theholder is over the age of 21 without requiring the birth date.
For this reason there are specific requirements that we need to call out for how paper credential schemas
may differ from digital ones. For example, a paper credential could allow some level of identity obfuscation
by only providing incomplete demographic information, such as the first and last letter of a name.
Paper credentials are built on the work of other GHP working groups. Thus, to some degree a large part ofour recommendation here is “encode the data the way they specify it elsewhere in GHP”.
Because there may be use cases where verification will be done without access to the Internet, paper
credentials and passes SHOULD be as “self-contained” as possible, meaning that all data that is external
to the credential can be cached in advance.
We request GHP implementers to specify with maximum detail each of their fields and field types in aschema. Knowing minimum and maximum sizes for each field allows an implementer to estimate the

The Good Health Pass Interoperability Blueprint85

minimum QR size where every payload can be represented. Specifying the precision of the field andencoding value sets into fixed enumerations significantly reduces the size of the field in bytes. Long field
types, like DIDs and UUIDs MUST be encoded in Base32URL to make sure they use the minimum amountof space in the QR.
Defining data type recommendations can significantly improve the size of the QR. If possible with theuse case, fields with Latin alphabets should encode their text only in UPPERCASE. This simple choicerepresents ~50% savings of the field size in represented bytes. Virtually every paper credential existing
today, from government IDs and passports, to credit cards and member cards, etc., uses UPPERCASE
only fields.
If the schema happens to have multiple dates and/or datetimes, a good option is to encode all datetimes
as positive integers representing the time passed since a chosen epoch (e.g. 1/1/1970). Ideally, the new
datetime format has a flag that marks the scale (days, hours, minutes, seconds, milliseconds or ticks) anduses an integer number of that scale between the given time and an arbitrary epoch. This method cansave a significant amount of space when compared to ISO8601 dates.
URLs or QRs with simple identifiers where more data can be downloaded directly from the issuer or acentralized server/blockchain, and thus allow tracing from that server, are not Good Health Passes.

6.3.6.2 Recommendations
6.3.6.2.1 FIT FOR PURPOSE
Paper credentials are being designed for use cases where the Internet is not available, but there is the
expectation that public keys and similar can be cached and refreshed occasionally.
A GHP-compliant paper credential or Good Health Pass:
1. MUST include the complete information set for the use case inside the QR.
2. MUST be designed with minimum data.
3. MUST be digitally signed using a method recommended by GHPC.
4. MUST NOT be a URL or a simple identifier.
5. SHOULD limit the inclusion of URLs into the payload.
6. SHOULD follow the W3C Verifiable Credentials data model.

6.3.6.2.2 QR CODE COMPATIBILITY
There is a limit to how much data can be reasonably stored within a QR code, and generally speaking
the smaller the size of the QR code, the better. QR codes internally have multiple encoding methods
and respond better to certain data encodings. Please see the “QR Image Specs for Printing/Displaying”
section for further considerations.
A GHP-compliant paper credential or Good Health Pass:
1. MUST specify the maximum payload size and estimate minimum printed QR size.
2. SHOULD encode highly random data, such as DIDs and UUIDs, in Base32URL.
3. SHOULD encode Latin-alphabet text as UPPERCASE ASCII.
4. SHOULD encode dates as differences in time since a given epoch.
5. SHOULD NOT duplicate information in the payload.

The Good Health Pass Interoperability Blueprint866.3.6.2.3 FORMAL DATA FIELD DEFINITIONS
It is worth noting that the EU Digital COVID Certificate9 specifies this information using JSON Schema10. A
GHP-compliant paper credential or Good Health Pass, for each field:
1. MUST specify optionality, minimum and maximum bounds.
2. MUST specify a format (date format, decimal number formats).
3. MUST specify an alphabet (UTF-8, UTF-16, numbers, ASCII, uppercase letters).
4. MUST specify a unit of account (celsius, meters, etc.).
5. MUST specify the precision (floating points, rounding methods, cropped names, etc.).
6. MUST specify normative simplifications (enumeration mappings, options, etc.).
7. MUST specify a formal semantic definition that SHOULD be a linked data URI.
8. SHOULD specify a regular expression to validate the field.

6.3.7

Problem #3: Credential Formats, Signatures, andMinimization Functions

6.3.7.1

Problem Description

Paper credentials are severely constrained by QR code size limitations, which means that credential
formats MAY need to be compromised in order to meet the requirements of paper based exchange. Thereis a limit to how much data can be reasonably stored within a QR code, and generally speaking the smaller
the size of the QR code, the better. QR codes internally have multiple encoding methods and respondbetter to certain data encodings. Please see the “QR Image Specs for Printing/Displaying” section forfurther details.
In order to enhance interoperability of all components, we are strongly advising Good Health Passes to
use the URI specification, where the schema type implies the minimization function used, as a defining
element for the rest of the QR message. URI encodings are extremely common data types for the QR
community. The adoption of this battle-tested standard guarantees stable deployment of the protocoland easy compatibility with most if not all scanning devices and applications out there.
Choices of formats, signatures and minimization functions should be optimized for ease of
implementation in high- and low-end devices while using the minimum amount of software dependencies
with preference for low-resource-consuming algorithms that have mature libraries available in many
programming languages. In order to guarantee that Verifiable Credentials are indeed “verifiable”, the GHP
specification recommends all elements of the credential (keys, schemas, minimization functions, etc.)
to be made free of cost, publicly available, well-defined and patent unencumbered, with wide access in
multiple programming languages.
QRs are by definition not human readable. But there is a difference between reading a QR with the phone’s
default camera app and reading the same QR with apps from the app stores (verifiers). How do holders
know the apps available to decode the QR are not exposing their information to unwanted parties? How
can holders be sure such apps are not using the information in their favor? Having to trust an app to
decode a QR just to verify if the sensitive information there is correct or existing is a bad user experience
design. We recommend implementers to create easily reviewable QRs, with directly legible fields using thedefault camera apps on available devices.
9

https://ec.europa.eu/health/sites/health/files/ehealth/docs/digital-green-certificates_dt-specifications_en.pdf
10 https://json-schema.org/

The Good Health Pass Interoperability Blueprint876.3.7.2 Recommendations
GHPC has designed this recommendation such that it can be implemented with free of cost, publicly
available, well-defined and patent unencumbered code, in multiple programming languages.
A GHP-compliant paper credential or Good Health Pass:

6.3.7.2.1

FIT FOR PURPOSE

1. MUST support issuing and verification of credentials in offline environments.
2. MUST include a unique reference to download public keys for verification.
3. MUST include references (not necessarily a direct link) to any other element that is needed toprocess, verify and understand the payload (conversion templates, minimization functions, schema
definitions, etc.).
4. MUST be formatted as a URI (RFC3986), where the schema type implies the minimization function.
5. SHOULD be easily readable by the holder, to confirm the information in the QR matches theirprivacy expectations.

6.3.7.2.2

CRYPTOGRAPHY

1. MUST include a cryptographic signature.
2. SHOULD use the signature suite(s) recommended in “Recommendation #5: Credential Formats,
Signatures and Protocols”.
3. SHOULD use signatures that minimize space and are easy to compute by low-end devices.

6.3.7.2.3

DATA MINIMIZATION AND ENCODING

1. MUST apply a data minimization function to adjust encoding of available W3C VC syntaxes (JSON,
XML, YAML, CBOR) to the QR; or use a VC syntax already designed for QR compatibility.
2. MUST define or reference all steps of the data minimization function being used and make it freely
available. Any holder or any verifier may revert the function and obtain the original payload.
3. MUST NOT use plain or unencoded Unicode strings on QRs. QR expects ISO 8859-1; use of Unicode
will likely cause faulty decoding and cryptographic verification failure.
4. SHOULD be optimized for ease of implementation in high- and low-end devices while using
the minimum amount of software dependencies with preference for low-resource-consuming
algorithms that have mature libraries in many languages.

6.3.7.2.4

MINIMIZATION FUNCTIONS

Choosing a Minimization Function
1. Decoders MUST support Option 1 and Option 2.
2. Encoders SHOULD use the option which encodes the smallest payload size.
Option 1: CBOR-LD encoded Multibase
Note that all JSON-LD contexts MUST be available at encoding time.
1. Encode the JSON-LD message using CBOR-LD. (https://digitalbazaar.github.io/cbor-ld-spec/)
2. Encode the CBOR-LD message as multibase (https://github.com/multiformats/multibase)
2.1. Encoders SHOULD use Multibase Base32
2.2. Encoders SHOULD NOT use any other encoding at this time; this may change
2.3. Decoders MUST accept Multibase Base32, and recognize other encodings

The Good Health Pass Interoperability Blueprint88

3. Prefix with CBLD: (UPPERCASE strongly preferred).
4. Create the QR code, with at least 25% error correction preferred.
The URI at step 3 is a valid URI according to RFC3986. When decoding:z the prefix MUST match CBLD: with a case-independent match.
z the last colon section separated component of the URI is always the encoded payload (this allows
for other components in the future, but their meaning is undefined).
Option 2: JSON-XT
JSON-XT is described here: https://jsonxt.io/. JSON-XT requires a template which describes all the data
being encoded.
1. Choose the template “resolver”, name and version.
2. Encode the JSON-LD (or any JSON) as JSON-XT. A valid RFC3986 URI is produced with the prefix
JXT:.
3. Create the QR code, with at least 25% error correction preferred.
Phase One (30 Day Horizon)
GHPC will recommend standard templates for JSON-XT encoding, including resolver name, templatename and version.

6.3.8

Problem #4: Security, Privacy, and Data Protection

6.3.8.1 Problem Description
Paper credentials cannot participate in privacy-preserving selective disclosure and zero-knowledgepresentation request and proof exchanges: whatever is in the credential is presented as a whole to theverifier. For this reason are there specific considerations that we need to call out for how paper credential
schemas may differ from digital ones. For example, a paper credential could allow some level of identity
obfuscation by only displaying incomplete demographic information, such as the first and last letter of aname.
A Good Health Pass gives full control to holders and it is generally the legal property of the holder. The
holder should be able to review the data encoded on the credential or pass and control the physicaldocument. Implementations MUST comply with local regulations on data retention and transmission(e.g., GDPR, HIPAA) which may impact any or all parties using the pass or credential. The holder MUST
have access to information about the security and privacy implications of the data on the credential orpass, and make decisions about which information to disclose to verifiers based on these implications
Implementers MUST consider implicit information sharing consent opportunities and risks. The holder
can, for instance, display parts of the pass or credential to a handheld scanner while obfuscating anotherpart of the credential. In this case, the consent is sufficiently well defined by physically masking theinformation the holder does not want to expose. Implementers MUST make sure that desire cannot be
circumvented by verifiers and/or additional cameras recording the holder.
If the implementation explicitly includes a path to destruction/revocation of a credential or pass, theimplementation should specify whether destruction/revocation will prevent recovery/replacement of thatpass. If the information in the pass or credential may be used to defraud or otherwise harm the holder, thepass or credential MUST incorporate security measures (such as a PIN or password) to mitigate this risk.
All multi-use Verifiable Credentials are traceable through data sharing between colluding verifiers. If
traceability is an issue for the use case, we recommend providing holders with a tear-off book of Verifiable

The Good Health Pass Interoperability Blueprint89

QRs that contain a nonce. This design element turns a multi-use element into a single-use, give away
card. If this is implemented, verifiers need to make sure to properly secure or destroy the evidence of thephysical QR in the same way they would protect and destroy the digital QR.

6.3.8.2 Recommendations
To meet the expectations of a Good Health Pass, a QR paper credential or pass:
1. MUST provide as much control of the physical document as possible to the holder.
2. MUST comply with local regulations on data retention and transmission.
3. MUST give information to holders about the security and privacy implications of the data.
4. MUST only reveal information with the consent of the holder.
5. MUST use encryption if the Verifiable QR can defraud or otherwise harm the holder.
6. SHOULD specify whether destruction/revocation will prevent recovery/replacement.
7. SHOULD NOT combine multiple information classes such as health and financial information.
8. SHOULD NOT include information not necessary to support the desired use case.
9. MAY print multiple different single-use paper QRs that are designed to be given away to eachverifier if verifier traceability is an issue.

6.3.9 Problem #5: Minimum Identity Binding
6.3.9.1 Problem Description
Typically, paper-based credentials that should be verifiable without contacting the issuer act as bearer
instruments, where the holder of the instrument is assumed to be its subject. While this is good for
privacy reasons, it does cause an issue with regards to potential misuse of credentials, for example bybeing presented by a person that is not the subject of the credential. Due to the static nature of paperbased credentials, another issue is that they generally could allow for replay attacks, allowing for repeatedusage (e.g., through copies). This is especially problematic in a situation where there is no unique
identifier for credentials that may originate from different issuers, using a variety of issuance processes
and/or systems.
In order to address these problems and reduce the risk of misuse, a minimum form of identity binding
should be implemented in paper-based credentials in such a way that it can be independently establishedthat the holder of a paper-based credential is also the subject of the credential. As the more informationis stored in a Verifiable QR code, the more likely the QR code can be used to uniquely track a person;
therefore we recommend the less information stored the better, including less precise individual fields.
For example, instead of storing a person’s full name and date of birth, it could store only the person’s
initials and year of birth, adding ambiguity to reduce traceability. Instead of storing the issuance date inmilliseconds, which can be used as an identifier, it could store in seconds. However, we recognize that
this may cause a conflict with the requirements of verifiers and the potential for creating a credential that
could be reused by someone it was not issued for.
When used in combination with other credentials (e.g., a ticket), the identity binding should remain
independent and bound information from the health-pass should not be propagated into any othercredential which serves a different purpose. While it may appear this is good for usability, the linked PII(Personally Identifiable Information) and/or PHI (Protected Health Information) significantly changes theregulatory status of those credentials, posing large challenges to the processors and controllers of thosecredentials.

The Good Health Pass Interoperability Blueprint90

6.3.9.2 Good Health Pass Design Requirements & Considerations
Since paper credentials cannot participate in automated digital identity verification protocols,
implementers MUST bind the record to an independently verifiable identifier of the person. The binding
can be strong (e.g., exact name, government-issued ID numbers, e-mails, phone numbers, biometric
information) or weak (e.g., initials of the user’s name, public database’s member ID), but it MUST be in
the credential payload or be linked to that payload.
The chosen method MUST allow manual identity checks by verifiers and should not rely on IDs that are
not openly accessible to independent verifiers (e.g., company controlled member/employer cards) or
identification mechanisms that allow a third party to control access to them. Weak binding is key forvulnerable populations such as undocumented immigrants, persecuted populations, and other minority
classes. It also enables easier implementation across a wide variety of issuers.
In order to strengthen the binding with the holder, authenticators such as passwords or PINs MAY beused, with the consideration that this could prevent misuse in cases where the original holder is not
actively involved. As such, it will generally not increase the level of assurance of the credential.
Paper credentials MAY have a second user binding mechanism using a digital multi-factor authentication.
By including contact information (e-mail, phone numbers, etc.) in the Verifiable QR, a verifier can senda message to verify the control of the contact information and authenticate the owner without the needfor an additional identity document. The same procedure can be used to unencrypt sensitive parts of the
Verifiable QR.

6.3.9.3 Recommendations
To meet the expectations of a Good Health Pass, a QR paper credential or pass:
1. MUST minimally bind to identifying information of the rightful holder.
2. MUST be independently verifiable with another form of identifying information.
3. SHOULD bind using commonly-used, publicly accessible, identifiers.
4. SHOULD allow for flexibility in assurance levels through its identity binding.
5. MAY bind to a multi-factor authentication option.
6. MUST ensure identifying information remains independently verifiable.

6.3.10 Problem #6: Trusted Physical Card Design
6.3.10.1		 Problem Description
QRs require physical space, either on a card or on a display. The following recommendations are intended
to describe what features such cards should consider.

6.3.10.2		 Good Health Pass Design Requirements & Considerations
The card MUST allow the holder to understand what is in their Verifiable QR. A good practice that is
implemented in virtually every other form of barcode-based paper credential is to expose the fields inside
the QR around the QR itself, as much as possible. However, sometimes the information in the QR might
not fit on the card or might not be desirable to be human-readable (e.g., a password). Due to such fringeuse cases, even though we believe all fields SHOULD be on the card, we are choosing to not require this.
Cards can include security features (e.g., branded cards, select materials, serial numbers, etc.) that add
protections to the cryptographic signature. We are particularly concerned about use cases where massive
unauthorized cloning can create a Denial of Service attack on the identity check procedures of verifiers.

The Good Health Pass Interoperability Blueprint

91

Vendors MUST carefully understand the risks of cloning the QRs and adopt measures accordingly.
Additional materials can provide protection against unwanted/unauthorized scanning, such as privacy
filters, folding designs, protective sleeves, etc. If labels/stickers are to be used,“tamper-proof”/“tamper-evident” labels can be implemented for scenarios where added security isrequired (where the risk/incentive of fraudulent activity is high).
Good Health Passes tend to be multi-use elements and MUST be designed with a specified longevity inmind. Certain materials (e.g., thicker papers, labels or PVC card) can also improve the speed of scanning
due to the need to keep the Verifiable QR flat during scanning.
For cards that contain more than one Verifiable QR, the design of the card MUST make obvious to theholder what each QR contains and how/where to use it. The same design MUST also allow holders to hideparts of the card, including other QRs and/or human-readable fields they don’t want to show to a verifier,especially if each QR contains different data classes (e.g., health information, financial information,
personally identifiable information).
When providing Verifiable QRs as independent stickers to be placed on cards, implementers MUST print
the information in the QR in human-readable fashion on the stickers themselves. This builds up theconfidence of holders by clarifying which QR has what data even before placing them on a card.
In case of using weather-sensitive printing mechanisms (e.g., thermal printers, soluble inks), holders must
be aware of the risks of losing the credential by temperature or water damage. If possible, card designers
should avoid such materials to enhance user experience. Card/label/paper printers should be capableof catering for large scale printing and simplicity of user experience (changing ribbons, etc.) at point ofissuance.

6.3.10.3 Recommendations
To meet the expectations of a Good Health Pass, a QR paper credential or pass:
1. MUST define minimum and maximum physical space for the Verifiable QR.
2. SHOULD design the card avoiding potential folding marks through the Verifiable QR.
3. SHOULD display all fields found in the QR Code legibly on the Card.
4. SHOULD be durable and/or easily reprintable.
5. SHOULD use thicker materials to enhance machine readability.
6. SHOULD label each QR to instruct holders what exactly it contains and how to use it.
7. SHOULD be designed for and/or use materials that block unauthorized reading.
8. SHOULD provide protections to enhance durability, resist abrasion, crumbling, tearing, scratching,temperature and water damage.
9. MAY use tamper-evident materials, for example, so a QR sticker could not be removed andreattached.

6.3.11 Problem #7: QR Image Specs for Printing/Displaying
6.3.11.1 Problem Description
QRs require physical space, either on a card or on a display. The following recommendations are intended
to facilitate the scanning and set up minimum requirements for low-end devices.

The Good Health Pass Interoperability Blueprint926.3.11.2 Good Health Pass Design Requirements & Considerations
Understanding what information can fit into a readable QR code takes into consideration the allowable
space in the card, the quality of the printer, and the expected distance between the QR code and the
QR scanner. We stress that by carefully defining the fields available for the issuer and the minimization
function, a vendor MUST be able to build the minimum and maximum payload configurations and verify if
both fit the available space, given the printing processes available, and are easily readable by the lowestresource QR scanner supported.
We recommend a minimum QR resolution as the following: each QR bit (each black and white square of
the QR) is composed of at least a 3x3 grid of printed dots or display pixels and a minimum of 0.4mm per
QR bit. Implementers should keep in mind that QR scanners have a maximum and minimum focusing
ability and if the QR bit is too small for the expected distance, the scanner will not be able to read. For
error correction, we recommend level Q (~25%) and require a minimum of level M (~15%).
The GS1 2D Barcode Verification Process Implementation Guideline11 design document provides acomprehensive overview of all the metrics implementers should review before deploying their solution.
The printed QR should be optimized for Symbol Contrast, Fixed Pattern Damage, Axial Nonuniformity,
Grid Nonuniformity, Modulation, Unused Error Correction.

6.3.11.3 Recommendations
To meet the expectations of a Good Health Pass, a QR paper credential or pass:
1. MUST follow the QR Code specification (ISO/IEC 18004:2015).12
2. MUST follow the GS1 2D Barcode Verification Process Implementation Guideline.
3. MUST be printed or displayed on a size where the QR’s bits per inch is at most a third of theprinter’s dots per inch or the display’s pixels per inch.
4. MUST be printed/displayed with a margin/quiet zone with the size of 4 QR bits.
5. MUST specify minimum QR printing size for given printing/displaying resolutions.
6. MUST be able to print the maximum payload in the minimum QR printing size.
7. MUST use a minimum Level M (15%) error correction.
8. SHOULD use a Level Q (25%) error correction.

6.3.12 Problem #8: Public Testing Suites
6.3.12.1 Problem Description
Every solution provider for verifiable credentials and passes should provide ways to test implementations
against their designs and allow implementers to determine compliance with the specifications.

6.3.12.2 Recommendations
To meet the expectations of a Good Health Pass, a QR paper credential or pass:
1. MUST design a Test Policy.
2. MUST create a Test Suite.
3. MUST allow implementers to INDEPENDENTLY claim compliance to the vendor’s mode of operation
if their implementation passes all tests.

11

https://www.gs1.org/docs/barcodes/2D_Barcode_Verification_Process_Implementation_Guideline.pdf

12 ibid.

The Good Health Pass Interoperability Blueprint93

4. MUST offer a complete set of credentials and passes for testing purposes that explore all
variables, formats, optionalities and the limits of the proposed credentials, including all variantsof cryptographic algorithms, signatures, minimization functions, QR images, and complete card
images and electronic display screenshots.
5. MUST offer a complete set of testing credentials signed with development and production keys thatcan be verified with development and production environments on a frequent basis.
6. MUST offer the Test Suite in a programming language-independent way.
7. MUST NOT require implementers to purchase specialized equipment or licenses from the vendor tovalidate the correctness of an implementation.
8. SHOULD offer an locally-runnable implementation of the test suite in the vendor’s preferredlanguage.
9. SHOULD provide meaningful feedback to implementers when a QR paper credential or pass does
not satisfy the requirements of the specification (beyond pass/fail).
10.SHOULD provide example data sets for minimum and maximum size that MUST be supported by
implementers.

6.3.13 Problem #9: Interoperability between Paper andDigital Credentials
6.3.13.1		 Problem Description
Paper credentials MUST be given equal weight in the GHP ecosystem. For equity and other reasons, no
one should be required to have an electronic device to use GHP. We also foresee the need for credentials
in highly constrained environments, and also the possibility that people MAY need to move between theseworlds (highly constrained and less constrained).

6.3.13.2		 Good Health Pass Design Requirements & Considerations
We are allowing for two possibilities for transcribing the “original” digital credentials into paper
credentials:z Two-way, which will be convertible back into the original digital formz One-way, which will not
One-way paper credentials do not have to be convertible back into their original digital form. We are notmaking a recommendation whether these be even exchangeable for a digital credential.

6.3.13.3		 Recommendations
Problem #3 outlines the data minimization function requirements, so we will not duplicate that
information here.

6.3.13.3.1 FIT FOR PURPOSE
1. A GHP-compliant implementation MUST support a paper credential option, MAY be one-way or
MAY be two-way
2. A two-way paper credential MUST be losslessly convertible back into its original digital form.
3. The one-way and two-way transformations MUST be well defined, as per Problem #3.
4. All verifiers that accept GHP-compliant digital credentials SHOULD also accept GHP-compliant
paper credentials
5. MUST expect and allow for the importation of the same credential/pass wallets that might haveother information for this record and might not be in sync with each other.
The Good Health Pass Interoperability Blueprint

94

7

Operational Infrastructure Recommendations

The Good Health Pass Interoperability Blueprint95

7.1 Recommendation #7: Rules Engines
7.1.1

Introduction to this Interoperability Challenge

Airlines are subject to many rules that govern every part of their operations. There are rules from theairport, from government agencies, and from the countries they fly between (and over). If an airline fails
to comply with any of these hundreds of rules, they may be subjected to fines and/or negative financial
impact due to operational delays.
In addition to the rules for operating aircraft, there are also rules specific to each passenger, including
rules around travel restrictions, disabilities, or other regulated accommodations.
Travel restrictions based on country of origin or health status have become commonplace during
the pandemic. These rules may change often and are often time-bound, complicating adherence bypassengers and air carriers alike. For example, a requirement that passengers must have tested negative
for COVID-19 within a certain time frame before arrival may impose its demands afresh every time there isa flight delay/cancellation or an airport closure.
Additionally, governments do not publish those rules consistently through specific channels or in astandard format. Rules are published using various means like circulars, website updates or a Notice toAirmen (NOTAM).
Most airlines choose to outsource this complexity and the expense of tracking all the rules to othercompanies who keep track of ongoing changes and can serve multiple airlines with the same data toachieve an economical benefit to all parties. One of the key products these rule-tracking companies offer
is called a Rules Engine. The Rules Engine stores the required rulesets and applies them on demand toensure airlines satisfy the regulatory requirements for the specific circumstances of each traveler.
The job of a Rules Engine is not only to determine compliance with rules, but also to determine both whatis additionally necessary to reach compliance and under what circumstances a non-compliant state may
be reintroduced after compliance is satisfied (e.g., visa expiry).
As COVID-19 has put air travelers and airline employees at greater risk, the requirement to manage thatrisk through the interpretation of health screenings, medical documents, and passenger attestationsin addition to the weight of public opinion and protecting personal privacy necessitates an integrated
approach.

7.1.2

Objective of this Drafting Group

Health screening is now just as much a part of air travel as the boarding pass. The current question is nolonger whether or not health screening should be done, but how it should be done for the benefit of allparticipants. With that in mind, the Rules Engine section of the document will describe issues with thecontemporary system of asserting health status to satisfy Rules Engine requirements, and proffer a seriesof recommendations and standards for advancing the status quo toward an efficient system that meetsthe needs and respects the rights of all parties.

7.1.3

Scope of this Drafting Group

Rules Engine systems are mature and in use today for most airlines. Their scope goes far beyond
passenger and flight crew health. Therefore we have focused our discussion only on what can be improved
with respect to the accurate determination of traveler health status in the context of a Rules Engine.

The Good Health Pass Interoperability Blueprint96

In those discussions, it quickly became apparent that we could not possibly address areas other than
air travel due to time constraints. However, we believe that most of the Hospitality and Tourism industry
could utilize this blueprint without airline grade rules engines to process their customer’s health statusbecause there are many companies available to build to their individual needs.
Additionally, we considered the role of Clinical Decision Support (CDS) systems in determining healthstatus. However, this was placed out of scope because the determination of what constitutes acceptablerisk is done hyper-locally. Not only do nations have their own determinations, but it is also possiblethat the airline, the airport, and the taxi service all have their own requirements. This is an area of great
concern, but it cannot be standardized. We believe that in a mature ecosystem the role of the CDS isrepresented in Figure 12 as item B.4. and the rules of the locale are represented as B.3. However, we
acknowledge a great deal of flexibility but be given to implementers to fill immediate needs while a global
standard for Medical Event Validation Rules remains unavailable.

7.1.3.1

Recommendd Rules Engine Subsystems

In Figure 12, The boxes on the right (Series B) show a subsystems view of how health status Rules Engines
might be integrated into contemporary Rules Engines. The diagram is not meant to be representative orcomplete with respect to Rules Engines. It is also not meant to imply that these subsystems or activities
cannot be integrated into a single system, such as they are with specialized rules engines that serve theairline industry today. However, a monolithic implementation may reduce a system’s agility in the face ofthe constantly developing rules seen during the pandemic. These also do not imply each node is network
aware all the time. Some implementations may require intermittent access to the internet or alternatemeans of data transfer.
While the process in Figure 12 moves from a health event to a health validation and then finally to a
travel assessment, in reality, the rules may be partially evaluated, evaluated in parallel, or evaluated in adifferent order. Additionally there will be branches and loops that require passengers to provide additional
information or conduct additional actions before travel.
Finally, the grey boxes in Figure 12 have been placed out of scope but are represented for context.

Figure 12: Subsystem view of Rules Engine Processes

The Good Health Pass Interoperability Blueprint977.1.3.1.1

SERIES A: CONTEMPORARY SYSTEM

A.1: Traveler attributes include any documentation or data that is specific to the traveler. This
includes any demographic information, travel documents, or personally identifiable informationcollected by the airline to facilitate compliance. Some of this is self attested by the traveler if
required like country of residence, or type of visit (i.e. business or leisure).
A.2: Travel attributes include any information about the flights a traveler plans to take including any
rescheduling, diversions, or other changes in itinerary on a per passenger basis.
A.3: The Contemporary Rules Engine analyzes the data from A.1 and A.2 in order to determine if a
traveler has what they need to travel in terms of compliance with pre-pandemic regulations andcontrols.
A.4: The Contemporary Rules Engine makes a health status determination based on customer
attestations of their own health, screening for elevated temperatures, and other methods toreduce the risk of disease transmission. For future versions, A.5 will become the place where
ad-hoc rules are applied which cannot be accommodated elsewhere including but not limited topassenger attested attributes.

7.1.3.1.2

SERIES B: HEALTH STATUS SUBSYSTEM ADDITIONS

B.1: The medical event that helps a passenger qualify for travel. This could be a vaccination, a test, or
something else.
B.2: The Medical Event Attestation is an authoritative document (paper or digital) that has therequired information that will be used to determine if the passenger meets the health related
requirements for travelling according to their itinerary. It is not self-attested by the passenger.
This attestation can be in the form of a credential, pass, or physical verification via paper orother means.
B.3: The Medical Event Validation Rules are used to decide whether the medical events presented in
the medical event attestations are considered sufficient for use in determining health status.
B.4: The Medical Event Validation Rules Engine applies the Medical Event Validation Rules to allpresented Medical Event Attestations and produces a single attestation that includes all valid
evidence valuable for the determination of Health Status. This MAY be done for a specificcontext such as air travel or it can convert the many forms of Medical Event Attestations into a
convenient machine readable format.
B.5: The Valid Medical Event Attestation is issued by the Medical Event Validation Rules Engine tothe holder in decoupled systems or provided directly to the Health Status Rules Engine in tightly
coupled systems. The Valid Medical Event Attestation MAY be used in multiple contexts.
B.6: The Health Status Rules are highly contextual and may come from multiple sources. They must
therefore be combined and deconflicted based on their context. For air travel, the context is
specific to each passenger’s itinerary.
B.7: The Health Status Rules Engine determines if the passenger meets the health related
requirements for traveling according to their itinerary. This is usually a complex decision basedon sound medical advice or opinion and may result in either a pass/fail or a probability/risk
score.
B.8: The Travel Health Attestation can be used at various stages of travel by various entities related
to the specific passenger’s itinerary. This includes but is not exclusive to the airline. It is not selfattested by the passenger. This attestation can be in the form of a credential, pass, or physicalverification via paper or other means.
The Good Health Pass Interoperability Blueprint98B.9: The Travel Status Rules Engine determines if all the requirements have been met for thepassenger to travel under current or expected conditions.

7.1.3.2 What Does the Recommended Architecture Change?
The architecture in Figure 13 is representative of changes that have already been made, and so represents
the current status quo. However, by breaking apart the subsystems and showing the component
subsystems, it is both easier to understand which subsystems need the most attention, and they canbe decoupled to decrease the scope of changes needed in each subsystem. Furthermore, each of thesesubsystems represent different areas of expertise and innovation that are necessary to implement Good
Health Passes as quickly as possible.

7.1.3.3 Why Have Separate Subsystems for Medical Event Validation,
		 Health Status, and Travel Status?
Splitting the functions of validating medical event attestations, evaluating health status and travel status
in system design acknowledges several facts.
1. There is no universal Medical Event Attestation [B.2] format or requirement. Vaccination records,
for example, might be digital or on paper as prescribed by the traveler’s health system, local
government, national government, or even the World Health Organization (WHO). Each of theseformats has different risk profiles for fraudulent use. Determining the validity of any given Medical
Event Attestation [B.2] will require some specialization and will rely on different data sources than
the subsequent Rules Engines [B.7 and B.9]. Ideally, improvements in Medical Event Attestations[B.2] will reach a point where a Medical Event Validation Rules Engine [B.4] becomes unnecessary,
but until that is universally true, those attestations [B.2] MUST be validated.
2. Evaluating health status is a constantly evolving task as more data becomes available with which toevaluate risks. Making the Health Status Rules Engine [B.7] a separate subsystem allows for quicker
adoption of fit-for-purpose software such as Clinical Decision Support (CDS) systems to evaluate
health status and provide an interoperable Travel Health Attestation [B.8] to the Travel Status Rules
Engine [B.9].
3. Sometime in the near future, it will be possible for travel rules to be executed in a trusted andverifiable way on the traveler’s phone without revealing any private information to the verifier.
However, it is unlikely (and possibly undesirable) that this new privacy preserving capability will
eradicate the need to depend on less technical solutions such as paper records. Therefore, it should
be expected that the Health Status Rules Engine [B.7] MUST continue to handle private informationthat is regulated differently across national boundaries and should then remain a separate
subsystem.
4. By separating the Health Status Rules Engine [B.7] from the Travel Status Rules Engine [B.9], we
acknowledge that the solutions for assessing health status do not necessarily belong with the travelindustry and that the healthcare industry or some other party may be better suited to create the
Health Status Rules Engine [B.7].
5. Separating the Health Status Rules Engine [B.7] from the Travel Status Rules Engine [B.9] enables
better portability of health passes between travel providers as long as the Travel Health Attestation[B.8] enables that portability with consistent data elements.

The Good Health Pass Interoperability Blueprint997.1.4

The Health Status Rules Engine

7.1.4.1

Challenge 1: Passenger Privacy

7.1.4.1.1

PROBLEM DESCRIPTIONAs health status requirements become more onerous for airlines and travelers, the technical simplicity
of providing airlines with direct access to patient records makes it a tempting solution. This option has
historical precedent. Vaccination cards have been used for decades as a medical provider’s attestation
regarding a health event. These health event attestations were functionally credentials because they could
be used in various contexts to assert that a particular health event (a vaccination) took place.
Digital credentials, however, cannot simply be a digitized paper credential because the Internet is theworld’s largest copy machine. Digital credentials MUST have additional properties to protect the people
and information they represent, prevent the inevitable copies from being usable by unauthorized entities,
and prevent forgeries. The ideal digital credential should prove the holder meets entry requirements
without revealing any additional information about the person or being correlatable to other contact
events with the holder.
In the near term, the Health Status Rules Engine will be the subsystem most consequential to privacy
outcomes. Passengers may provide Medical Event Attestations in many forms, but the Health Status
Rules Engine MUST be able to validate those attestations through inspection or verification and produce
its own attestation in the form of a pass that will be machine readable by the Travel Status Rules Engine.
This pass MUST protect the passenger’s private information while also protecting the airline from
regulatory penalties due to the misuse of private information or the failure to comply with regulatory
standards for traveler health status.

7.1.4.1.2

GOOD HEALTH PASS DESIGN REQUIREMENTS & CONSIDERATIONSIn this section, we will not cover inputs to the Health Status Rules Engine. While these Health Event
Attestations would ideally be digital credentials imbued with all the privacy protecting features of a Good
Health Pass, this cannot be controlled nor expected by the Health Status Rules Engine. In fact, if that ever
becomes a global standard, there will be no need for the Health Status Rules Engine.

7.1.4.1.3

HEALTH STATUS RULES ENGINE PRIVACY REQUIREMENT:A good Health Status Rules Engine MUST not collect, store, process, analyze, or retransmit data that is
unnecessary for follow-on transactions with the passenger to which the data refers unless it is maintainedon behalf of and with the consent of that passenger or their guardian.

7.1.4.2 Challenge 2: Health Status Rules
7.1.4.2.1

PROBLEM DESCRIPTION

Establishing rules to apply within the Health Status Rules Engine is a complex issue on its own. First, onemust determine what the authoritative source of rules is in a specific context. Second, one must interpret
those rules and place them in a machine readable format. Finally, one must apply those rules consistently
across multiple types of health event attestations (vaccination records, tests, etc.).
Providers of Rules Engines will recognize these challenges as their raison d’être. However, there are
special circumstances that make health status evaluations more complex. The line of authority is notalways clear as recommendations from health institutions are subjected to differing interpretations ofclinical guidelines and mercurial political proclamations. This complexity is deepened by the constantmisinformation fueled by pay-per-click advertising and the malevolent intentions of state sponsored
information warfare. However, Health Status Attestations are too important to allow interference from anoisy information environment. Therefore, for Health Status Attestations to have the desired efficacy, the

The Good Health Pass Interoperability Blueprint100rules that generate them should be authoritative and verifiable. Ideally, these rules would also be machinereadable in a way that would facilitate automated combination and deconfliction.
Finally, it is imperative that public trust be maintained. Transparency is the only tolerable course for theapplication of access controls to the public. Rules being used to determine travel eligibility based onhealth status MUST be made public in both the plain language and machine readable forms. Doing so will
go a long way in maintaining the trust of the public, and help the public understand what they need to do
before a travel decision is funded. Eventually, rules published in a Verifiable Presentation Request format
along with Medical Event Attestations in a Verifiable Credential format that supports selective disclosure
could enable passengers to generate their own verifiable Health Status Attestation without ever sharing
any medical or personal information.

7.1.4.2.2

GOOD HEALTH PASS DESIGN REQUIREMENTS & CONSIDERATIONS

1. A good Health Status Rules Engine MUST publish both the plain language and machine readable
rules along with references to the authoritative sources of those rules.
2. A good Health Status Rules Engine SHOULD use an open standard or published rules language.
3. A good Health Status Rules Engine SHOULD be able to verify the sources of the rules it is applying
to passengers.
4. A good Health Status Rules Engine SHOULD execute rule assessments in a trusted execution
environment utilizing cyber security best practices.
5. A good Health Status Rules Engine SHOULD provide passengers with the rules that are being
applied to them either in writing or by reference.

7.1.5

The Travel Status Rules Engine

7.1.5.1

Challenge 3: User and Passenger Experience

7.1.5.1.1

PROBLEM DESCRIPTIONThe Travel Status Rules Engine depicted in Figure 12 represents the final decision gate regarding apassenger’s eligibility to travel. The output of this Rules Engine is a continuous process that starts when
the passenger signals an intent to travel and ends when the itinerary has been completed. The airline pays
for the Rules Engine because it outsources complexity and risk by moving most of the processing outsideof the airport.. This allows airlines to go back to pre-COVID-19 processes and staffing levels. A good Rules
Engine must also consider the passengers who don’t want any surprises at the airport.
The status quo of person-to-person self-attested regulatory compliance is untenable if the regulations
are to have their desired effect. Not only does the person-to-person model increase expenses and slow
throughput, but it also risks the safety of passengers and employees by creating more vectors of infection.
Additionally, the earlier a health status assessment can be made13, the more costs are reduced for airlines
and passengers. Early status decisions also prevent the more frustrating late stage congestion anditinerary interruptions.

7.1.5.1.2

GOOD HEALTH PASS DESIGN REQUIREMENTS & CONSIDERATIONS

A good Travel Status Rules Engine MUST accept Health Status Attestations compliant with the Good
Health Pass requirements.

13 While earlier assessments are better in general, they must remain within the limits of usability. They cannot bedone so early that the health status or the rules surrounding the itinerary may have changed.

The Good Health Pass Interoperability Blueprint1017.2 Recommendation #8: Trust Registries
7.2.1

Introduction to this Interoperability Challenge

Trust in the Good Health Pass (GHP) digital trust ecosystem depends on the ability to verify thatissuers – and in some cases verifiers – are authorized under a GHP-compliant governanceframework. As simple as that may sound, being able to do this securely – at scale, online or offline,
across diverse jurisdictions and governance frameworks – is a non-trivial problem. This is the challenge ofdesigning and implementing GHP-compliant trust registries.

7.2.2

BackgroundAs decentralized digital trust infrastructure based on decentralized identifiers (DIDs) and verifiable
credentials has emerged, it has introduced a new problem: how to extend trust across the trust
boundaries that have traditionally been established either by: a) firewalls and internal networks, or b)hierarchical or federated public key infrastructures (PKIs).
The atomic building blocks of this new decentralized trust infrastructure are decentralized identifiers(DIDs). Currently in the final stage of standardization by the W3C (see the W3C DID Core 1.0
Specification), a DID is a new type of URI—the open standard globally unique identifiers (specified
by IETF RFC 3986) that are the foundation for the World Wide Web. The big difference is that a DID isgenerated cryptographically. This means:
1. A globally unique DID can be generated without the use of a centralized registration service (such as
is required with domain names, phone numbers, IP addresses, etc.)
2. Each DID can be cryptographically bound to exactly one DID document that contains theassociated public key(s) or other metadata under the control of the DID controller.
3. The entity (person or organization) in control of a DID—called the DID controller—cancryptographically verify control of the DID without the use of an external service provider.
4. DIDs can be free or extremely low cost.
All of this means DIDs can be generated quickly, easily, and in volume, either by individuals ororganizations as needed.
So the question becomes: how do you establish trust between entities—in particular individuals ororganizations—when they each control their own DIDs?
With traditional PKI systems, such as those based on X.509 public key certificates, this is accomplished
via a public key directory (PKD) model. In a PKD, the root of trust is a top-level directory, typically run
by a certificate authority (CA). The root CA self-signs its own public key certificate together with thecertificates of its delegates. The delegates, in turn, sign the certificates of their delegates, and so on.
To verify a public key certificate in this X.509 certificate chain, the verifier must follow the delegation
links and verify the digital signatures in each of these certificates (“walk the chain”) back to a root CA toestablish cryptographic trust. (To establish human trust, the verifier needs to decide if it trusts the root
CA.)
This same type of delegated trust infrastructure can be implemented with DIDs, only it can be simpler
and more flexible. Since every DID controller generates their own DIDs and can cryptographically verify
control over them, centralized CAs are no longer required to serve as roots of trust. Instead, any DID
controller can serve as its own root of trust by establishing its own governing authority and publishing its
own governance framework. Then that governing authority can make the list of DIDs it trusts available tothe members of its ecosystem via a network service called a trust registry.

The Good Health Pass Interoperability Blueprint

102

There are several known solutions to provide evidence that an issuer or verifier is “trusted” under aspecific EGF. These options include:z Trust Registry14 - Providing a list of authoritative issuers or verifiers that is available inside theecosystem. This Trust Registry approach allows a Governance Authority to manage the membershipof issuer and/or verifiers that they are responsible for.
z Verifiable Credentials - in the future, credentials could be issued to verifiers and issuers that can beused as part of a credential chain.
While both alternatives have merit - and other options exist - under the GHP Blueprint the first option(Trust Registry) is recommended and this section describes the recommendations. The Trust Registry
option was selected for the following reasons:z Expediency - making the data available using a RESTful interface is well known and approachable
for nearly all organizations can easily adopt. The goal of the GHP Blueprint is to provide guidance for“good” that can be quickly and effectively implemented. While we imagine that different solutions
will evolve, the goal was to establish a simple baseline that the majority of implementers can adopt.
z Simplicity - While other solutions (e.g. using Verifiable Credentials that indicate authority) provide
potentially more elegant solutions, there are complexities and decisions that each ecosystem willneed to consider and make decisions about. These design decisions are broad enough that thetime to execution was deemed too long. Further, individual ecosystems will, correctly, pick different
approaches that better meet their needs.
Figure 13 provides a conceptual overview of where a trust registry fits into the GHP ecosystem:

Figure 13: Conceptual overview of the Good Health Pass digital trust
ecosystem showing the core role of a trust registry
It is critical to note that Figure 13 is a diagram of just one participating governing authority and its
associated trust registry. The Good Health Pass digital trust ecosystem can have as many governing
authorities and trust registries as are necessary to serve the overall ecosystem of ecosystems (see“Recommendation 9: Governance and Trust Frameworks”) for more details of this governancearchitecture). As shown in Figure 14, all of these governing authorities and trust registries are peers—
there is no “top-level” root of trust.

14 aka Member Directories in Aries RFC 0289

The Good Health Pass Interoperability Blueprint

103

Figure 14: The peer trust architecture of the GHP decentralized PKI
Furthermore, with this decentralized PKI architecture, trust registries are not restricted to justsupporting DIDs and DID chains—they can be designed to support both DID chains and X.509 certificate
chains, thus providing a bridge between these two worlds. Architects of decentralized digital trust
infrastructure at the ToIP Foundation and other industry organizations are developing specifications forthis hybrid architecture.
While this hybrid trust registry architecture is the long-term ideal for the Good Health Pass digital trust
ecosystem, the initial recommendations in this document only need to encompass GHP-compliant trust
registries as shown in Figure 15 (see “Recommendation 5: Credential Formats, Signatures, and Exchange
Protocols” for more about this diagram). In other words, only direct issuers of GHP-compliant healthpasses are required to be registered in GHP-compliant trust registries. Issuers of other non-GHP healthcredentials MAY or MAY NOT use GHP-compliant trust registries.

Figure 15: Direct issuers of GHP-compliant health passes MUST use GHP-compliant
trust registries. Issuers non-GHP health credentials are encouraged to use GHPcompliant trust registries but may use other trust registry solutions that can beverified by GHP-compliant health pass issuers.
The Good Health Pass Interoperability Blueprint

104

The “bridge” between GHP-compliant trust registries and other non-GHP trust registries (such as X.509based PKDs) can be provided by issuers in the travel domain who choose to act as verifiers of non-GHP
health credentials from issuers using non-GHP trust registries. The travel domain issuers can thenissue GHP-compliant health passes that are verifiable using a GHP-compliant trust registry.

7.2.3

Objective of this Drafting GroupThe objective is to recommend solutions for each of the key challenges in delivering a globallyinteroperable decentralized trust registry network, including resolving and accessing peer GHP-compliant
trust registries, establishing a common trust registry protocol, verifying both authorized issuers andauthorized verifiers, supporting offline verification, and providing sufficient trust assurance. These
objectives will be met if the recommended design is: a) compatible with the GHP Principles, b) consistent
with the other GHP recommendations, and c) enables GHP ecosystem members to answer two basic
questions:
1. Is an issuer authorized to issue a specific type of credential or pass under a specific ecosystemgovernance framework (EGF)?
2. Is a verifier authorized to request a specific type of credential or pass under a specific EGF?

7.2.4

Problem #1: How can a verifier know an issuer isauthoritative in the GHP digital trust ecosystem?

7.2.4.1 Problem Description
To verify a proof of a GHP-compliant digital health credential or pass from a holder, a verifier needs toanswer the following questions:
1. Was the credential or pass issued by an issuer authorized under a GHP-compliant specificecosystem governance framework (EGF) to issue that type of credential or pass at the time it wasissued?
2. Is the digital signature on the proof verifiable using the issuer’s public key?
3. Does the proof contain the data necessary for the verifier to make a trust decision?
GHP trust registry architecture is designed to answer the first question. Strictly speaking, the second
question is out of scope, however our proposed DID-based design will also enable the verifier to obtainand verify the issuer’s public key. The third question is out of scope for GHP.

7.2.4.2 Good Health Pass Design Requirements and Considerations
To be consistent with the rest of the GHP recommendations, the Trust Registries group established thefollowing high-level design principles:
1. Decentralized peer trust. The design MUST not require a single root of trust, but rather support
a peer trust model between all participating governing authorities that enables each authority todetermine its own policies for registering:
1.1. Issuers.
1.2. Verifiers.
1.3. Other peer trust registries.
2. Simplicity. The design SHOULD be as simple as possible to encourage rapid development, aminimal attack surface, and broad adoption. GHP SHOULD not push design constraints on
implementers beyond the most basic requirements.

The Good Health Pass Interoperability Blueprint105

3. Open standard. Although the design MAY enable access control for governing authorities who
require it, it MUST be based on easy-to-implement open standard royalty-free specifications.
4. Protocol-based. The design MUST specify a common interoperable trust registry protocol rather
than rely on any specific trust registry implementation. How a governance authority implements
the back-end system for a trust registry (e.g., database, directory, or distributed ledger technology;
administration; redundancy; backup; scalability, etc.) is out of scope for these recommendations.
5. Performant. The design SHOULD respond to trust registry queries with approximately the same
performance as high-performing commercial websites.

7.2.4.3 Recommendations
7.2.4.3.1

GOVERNING AUTHORITIESA GHP-compliant governing authority:
1. MUST publish at least one trust registry DID in their specific EGF.
2. MUST specify at least one trust registry service endpoint for issue authorization in the associated
DID document using the trust registry service endpoint type URI specified in the GHP Trust
Registry Protocol Specification.

7.2.4.3.2 TRUST REGISTRIESA GHP-compliant trust registry:
1. MUST be identified by a trust registry DID generated using a GHP-compliant DID method.
2. MUST support all mandated requirements of the GHP Trust Registry Protocol Specification.
3. SHOULD incorporate throttling, DDOS protection, etc.
4. MAY limit the DID methods permitted to be used for the registered DIDs to a subset of the GHPcompliant DID methods.

7.2.4.3.3 TRUST REGISTRY PROTOCOLThe GHP trust registry protocol:
1. MUST be an open standard royalty-free specification.
2. MUST be specified in either:
2.1. A GHP Trust Registry Protocol Specification.
2.2. A more general purpose trust registry protocol specification if it meets all the requirements inthese recommendations.
3. MUST support trust registry service endpoint resolution using GHP-compliant DID methods.
3.1. SHOULD support the GHP X.509 Subject Alternative Name URI Specification.
4. MUST provide a registration method.
5. SHOULD provide a revocation method.
6. SHOULD provide a verifier access request method.
7. MUST support queries consisting of the following parameters to enable issuer authorization:
7.1. Trust registry DID
7.2. Issuer DID
7.3. Verifiable credential type URI
8. MUST support queries of the following parameters for cross-registration of peer trust registries
8.1. Trust registry DID

The Good Health Pass Interoperability Blueprint1068.2. Verifiable credential type URI
8.3. Verifiable credential issuance date
9. MUST return exactly one of the following status values:
9.1. Not found
9.2. Current
9.3. Expired (not renewed after the previous valid registration period)
9.4. Terminated (voluntarily terminated by the issuer)
9.5. Revoked (involuntarily terminated by the governing authority)
10.MUST return exactly two date values (formatted to comply with RFC3339, as UTC/Z - with nooffset):10.1. AuthorizationStartDate - which indicates the data that the Issuer’s authorization started.
10.2.AuthorizationEndDate - which may be null for Issuers that are currently, at time of the query,
an Authorized Issuer. If an Issuer is not currently an Authorized Issuer, the date that they lostthat status will be returned.

7.2.4.3.4 ISSUERS
GHP-compliant issuers:
1. MUST be identified by an issuer DID generated using a GHP-compliant DID method.
2. MUST register the issuer DID in the trust registry of any specific EGF under which the issuer wishes
to issue GHP-compliant credentials.
3. MUST issue GHP-compliant verifiable credentials that meet the following requirements:
3.1. The verifiable credential includes a claim specified in the GHP Verifiable Credentials
Specification whose value is the trust registry DID for the specific EGF under which thecredential or pass was issued.
3.2. The value of the verifiable credential issuer ID is the issuer DID registered in the trust registryidentified by the trust registry DID.
3.3. The value of the verifiable credential type is a GHP credential type URI specified in the GHP
EGF.

7.2.4.4 Recommended Timelines
7.2.4.4.1

PHASE ONE (30 DAY HORIZON)

GHP-compliant specific governing authorities:
1. SHOULD manually maintain a list of authorized issuers in a DID document using a did:web: URL as
specified GHP Trust Registry Protocol Specification.
2. SHOULD participate in development of the GHP Trust Registry Protocol Specification.
3. SHOULD publish their trust registry development plans.

7.2.4.4.2 PHASE TWO (90 DAY HORIZON)
GHP-compliant specific governing authorities:
1. SHOULD publish their trust registry policies and specifications in their specific EGF.
2. SHOULD have their trust registry implemented.
3. SHOULD pass a GHP-compliant trust registry protocol test suite.
4. SHOULD maintain a list of the trust registry DIDs of other GHP-compliant peer governing
authorities.
The Good Health Pass Interoperability Blueprint1077.2.4.4.3 PHASE THREE (180 DAY HORIZON)
GHP-compliant specific governing authorities:
1. MUST have implemented a GHP-compliant trust registry.
2. MUST meet all requirements in their specific EGF.

7.2.5

Problem #2: How can a holder verify an authorizedverifier in the GHP digital trust ecosystem?

7.2.5.1 Problem Description
In some cases, the governing authority for a specific EGF MAY wish to support a specific privacy anddata protection feature for holders using GHP-compliant digital wallets within its ecosystem: verifier
authorization. This can take one of two forms:
1. Required authorization of verifiers. In this case the trust registry for the specific EGF will not allow
access to unauthorized verifiers, so they are unable to fully verify a GHP-compliant credential issued
under that specific EGF.
2. Holder warning of unauthorized verifiers. In this case an unauthorized verifier still has access tothe trust registry, but a GHP-compliant wallet will automatically warn the holder when it receives apresentation request from an unauthorized verifier.
This capability, often referred to as “verifying the verifier”, is illustrated in Figure 16.

Figure 16: If supported in a specific EGF, a holder’s digital wallet can query
the trust registry for that ecosystem to verify that a verifier isauthorized

7.2.5.2 Good Health Pass Design Requirements and Considerations
The preceding requirements for the GHP Trust Registry Protocol Specification are easily extended toinclude verifier authorization.

The Good Health Pass Interoperability Blueprint1087.2.5.3 Recommendations
7.2.5.3.1

GOVERNING AUTHORITIESA GHP-compliant governing authority:
1. MAY specify requirements for verifier authorization in their specific EGF.
2. MAY specify a separate trust registry service endpoint for verifier authorization in the associated
DID document using the trust registry service endpoint type URI specified in the GHP Trust
Registry Protocol Specification.

7.2.5.3.2

TRUST REGISTRY PROTOCOLThe GHP trust registry protocol:
1. MUST support queries consisting of the following parameters to enable verifier authorization:
1.1. Verifier DID
1.2. Presentation definition type URI
1.3. Request datetime
2. MUST return exactly one of the following status values:
2.1. Not found
2.2. Current
2.3. Expired (not renewed after the previous valid registration period)
2.4. Terminated (voluntarily terminated by the issuer)
2.5. Revoked (involuntarily terminated by the governing authority)

7.2.5.3.3

VERIFIERS

GHP-compliant verifiers:
1. MUST comply with the verifier authorization requirements of a specific EGF if the verifier wishes torequest GHP-compliant credentials issued under that specific EGF.
2. MUST be identified by a verifier DID generated using a GHP-compliant DID method.
3. MUST make a GHP-compliant presentation request that meets the following requirements:
3.1. The presentation request includes the verifier DID and the GHP presentation definition URI.
3.2. The presentation request is digitally signed by the verifier using the private key associatedwith the verifier DID (See section 4.5 of DIF Presentation Exchange v1.0.0).

7.2.5.3 Recommended Timelines
This trust registry feature SHOULD be implemented by the specific governing authorities who require iton the same timeline as issuer authorization (Problem #1).

7.2.6

Problem #3: How can a GHP-compliant trust registry
support offline verification if needed?

7.2.6.1 Problem Description
In some situations, verifiers may not have access to online trust registries. Examples include poor or
lapsed connectivity (e.g., remote border crossings), firewall restrictions, or networks that are air-gappedfor security reasons. In other cases offline caching may be required for performance reasons. For allthese reasons, GHP trust registry architecture SHOULD support offline verification of authorized issuers.

The Good Health Pass Interoperability Blueprint109

(Offline verification of authorized verifiers by holders is considered such a small edge case that it will not
be addressed).

7.2.6.2 Good Health Pass Design Requirements and Considerations
Offline replication of directories and PKDs is a well-understood problem space. Furthermore, thesimplicity of the GHP trust registry design and GHP Trust Registry Protocol Specification should makeit relatively straightforward to add support for offline verification. However any data synchronization
protocol that also needs to be secure and reliable is non-trivial to implement.
Trust Registries MAY also publish the information they contain in machine readable form for offline use.
This allows the information to be downloaded and cached, enabling synchronization for verification ofissuers and verifiers. Schema information may also be used to cache appropriate information necessary
for offline credential exchange.

7.2.6.3 Recommendations
7.2.6.3.1

GOVERNING AUTHORITIESA GHP-compliant governing authority:
1. MUST specify their specific EGF whether their trust registry service supports offline verification.

7.2.6.3.2

TRUST REGISTRIES

If required by its governing authority, a GHP-compliant trust registry:
1. MUST implement support for data synchronization as specified in the GHP Trust Registry
Protocol Specification.

7.2.6.3.3

TRUST REGISTRY PROTOCOLThe GHP trust registry protocol:
1. MUST specify at least one data synchronization method (such as batch downloading) for offline
usage.

7.2.6.3.4

VERIFIERS

GHP-compliant verifiers:
1. MAY implement offline verification if supported by a trust registry.
2. MUST follow cache refresh or other offline verification policies specified in the specific EGF.

7.2.6.4 Recommended Timelines
Offline verification SHOULD be implemented as demand arises in the GHP ecosystem.

7.2.7 Problem #4: How can a GHP-compliant trust registry
provide a high level of trust assurance?
7.2.7.1

Problem Description

Trust in a GHP trust registry is rooted in its governing authority, its specific EGF, and most concretely inthe trust assurance framework section of the specific EGF. The challenge is how GHP-compliant trust
registries and their associated trust assurance frameworks should be designed to provide high levels oftrust assurance.

The Good Health Pass Interoperability Blueprint1107.2.7.2

Good Health Pass Design Requirements and Considerations

The design of a trust assurance framework for a trust registry is a complex problem that depends on
many factors unique to the governing authority, the trust registry implementation, and the digital trust
ecosystem being served. There is no single path to managing trust, rather it is a layered process thatinvolves intent, activities and controls. Aspects of managing trust that are particularly important to theimplementation and operation of a GHP-compliant trust registry include:z Credibilityz Reputationz Protection of trust registry participantsz Operational performancez Indemnification and operation within a trusted legal jurisdiction

7.2.7.3

Recommendations

NOTE: Implementing these recommendations can vary from trivial to very complex depending on therisk exposure associated with the trust registry operator(s) and users. The following is intended to be an
essential list of items to consider, but SHOULD be addressed at a level appropriate for each implementer.
There are very few MUSTs, and a wide latitude is allowed for how they are addressed.

7.2.7.3.1

GOVERNING AUTHORITIESIn a GHP-compliant specific EGF, a governing authority:
1. MUST follow industry best practices to the extent possible in the design, implementation andoperation of the technical components of the trust registry.
2. MUST define the operational constraints, obligations, authority and other permitted actions of thetrust registry operator
3. MUST define the relationship(s) between the trust registry operator and parties allowed to makechanges to the registry
4. MUST define the relationship(s) between the trust registry operator and the consumers of the data
maintained by the registry
5. MUST establish policies providing sufficient monitoring and enforcement of the requirements of thespecific EGF that apply to the trust registry operator.
6. MUST clearly identify who holds legal liability for the data contained in registries and properly
indemnify the trust registry operator for its role in maintaining the registry.
7. SHOULD promote transparency, peer review, ongoing awareness of system flaws and correction ofimportant flaws.
8. SHOULD ensure the trust registry operator has sufficient capital and resources to maintain levels of
operational availability that are appropriate for the participants of the trust registry ecosystem.

7.2.7.3.2

TRUST REGISTRY OPERATORS

Operators of GHP-compliant trust registries:
1. MUST employ detection and prevention controls to restrict and log participants creating andupdating entries in the registry.
2. MUST be able to enforce accountability of the parties permitted to alter the registry in conformancewith trust registry requirements.
3. SHOULD seek to maintain reputational trust by continuously and vigorously addressing bothinternal and external issues that would serve to diminish the perception of the operator, including

The Good Health Pass Interoperability Blueprint111

public relations issues, solvency issues, accuracy issues, security issues, system performanceissues, inappropriate actions by executives, employees, partners and participants, as well as others.
4. SHOULD establish and maintain criteria to identify and screen candidates for participation thatalign with the goals and expectations of the trust registry.
5. SHOULD establish and maintain criteria for expected performance memorialized in a formal service
level agreement between the operator and external participant.
6. SHOULD have formal mechanisms in place to:
6.1. Limit the possibility that private or proprietary information may be leaked to unauthorizedparties.
6.2. Remediate the effects of leaked information identified in breaches and address root causes.
6.3. Periodically audit the accuracy and integrity of data maintained by each role defined in its
trust assurance framework.
6.4. Remediate control deficiencies identified within audits.
7. MUST set expectations with participants regarding operational availability.
7.1. I t is anticipated that ecosystem availability needs MAY vary widely. Some trust ecosystems
MAY require global 24/7 operation of a trust registry to meet the needs of its participants
whereas others MAY only require part-time or intermittent operation. The key is that the levelof operations MUST sufficiently match the expectations of the participants.
8. SHOULD minimize operational downtime and performance degradation resulting from issues
that could be reasonably anticipated (e.g., funding, political, infrastructure, technical, process andpeople).
9. SHOULD implement operational practices to minimize impact, mitigate damages and hasten
recovery of anticipated potential downtime or performance degradation events.
10.SHOULD put technical controls in place with system users to protect the system from low andinconsistent performance and responsiveness.
11. SHOULD have actionable plans in place to mitigate the impact of sub-optimal capital and resources.
12.SHOULD have plans in place to limit the duration of any negative impact.
13. SHOULD, in the event that operations can no longer be sustained or a decision is made to cease
operations, either:
13.1. Seek an orderly transfer of data and operations to another GHP-compliant trust registry
operator, or
13.2. Seek an orderly shutdown which includes proper disposition of data according to jurisdictional
requirements and notification of the originators and consumers of registry data.

7.2.7.4

Recommended Timelines

Governing authorities SHOULD follow the recommendations in this section as they apply to the each of
the trust registry implementation phases recommended in Problem #1.

7.2.8

Interoperability Testing Recommendations

1. A test suite for implementations of the GHP Trust Registry Protocol described in theserecommendations SHOULD be developed in parallel with the specification of the protocol itself.
2. Implementations of GHP-compliant trust registries SHOULD begin testing against this test suite assoon as possible.
3. A GHP Trust Registry Technical Implementation Guide SHOULD be developed in conjunction withthe development of the specifications and test suite.
The Good Health Pass Interoperability Blueprint112

7.3 Recommendation #9: Governance andTrust Frameworks
7.3.1

Introduction to this Interoperability Challenge

Interoperable digital trust infrastructure requires more than just technology. It requires that the membersof a digital trust ecosystem agree on the business, legal, and social policies and rules they will follow toachieve their trust objectives. This collection of policies, rules, and specifications is called a governanceframework – a term that includes a trust framework (as that term is generally used in public key
infrastructure (PKI) and federated identity systems) along with additional governance components
needed for transitive trust across independent digital trust ecosystems.
As decentralized digital trust infrastructure has evolved, governance frameworks are also being
specialized for each layer of infrastructure. In particular, the Trust over IP (ToIP) Foundation is developing
standard models and best practices for governance frameworks for each of the four layers of the ToIP
stack as shown in Figure 17.
Trust over IP Governance Stack

Trust
overIP
IPGovernanceTechnology Stack
Trust
over
Stack

Ecosystem Governance Frameworks

Application Ecosystems✓ Member Directory

Governance
Authority

Governance
Framework✓ Auditor✓ Auditor Accreditor

Data Exchange Protocols

Governance
Authority

Governance
Framework✓ Authoritative Issuer

Governance
Framework✓ Transaction Author

Publishes

Governance
Authority

Governance
Framework✓ Transaction Endorser✓ Stewardof

Verifier

Peer DIDs
Connection
Agent / Wallet

Agent / Wallet

Public Utilities

Utility Governance Frameworks

Layer 1

Pro

Trust

✓ Software Provider✓ Agency

Holder

DIDComm Peer to Peer Protocol✓ Hardware Provider

Publishes

Governance
Authorityable
Veriﬁ entialdCre

Issuer✓ Insurer

Provider Governance Frameworks

Layer 2V

✓ Credential Registry

Publishes

Layer 3

Digital Trust Ecosystem

Digital Trust Ecosystem

Credential Governance Frameworks

V

Publishes

Layer 4

DID Method

DID Method

DID Method

Utility

Utility

Utility

Figure 17: The four layers of governance in the ToIP stack for decentralized digitaltrust infrastructure
From this perspective, the goal of the Good Health Pass Collaborative (GHPC) is to create a complete
ToIP Layer 4 digital trust ecosystem that is governed by an ecosystem governance framework. Given
the global scope, multiple stakeholders, overall complexity, and urgency of the task, development of
this governance framework is one of the most critical tasks for the GHPC. This document will convey
the overall recommendations of the Governance Framework Drafting Group for the development anddeployment of the Good Health Pass Ecosystem Governance Framework.

The Good Health Pass Interoperability Blueprint113

7.3.2

Background

The COVID-19 pandemic and its devastating effects on societies and economies are well documented –governments worldwide have adopted various restrictions on mobility and public gatherings to limit thevirus’ spread. Vaccination campaigns are underway globally, and health systems or solutions meant toalleviate the pandemic’s effects have been pressed into service with the goal of safely reopening society
as soon as possible.
To prevent these initiatives from operating as a series of unconnected solutions that enable siloing,
vulnerability, and mismanagement of user health data, the GHPC has focused on solving the key
challenges to interoperability – the problems we need to solve to standardize information sharing
mechanisms and achieve scalability, greater efficiency, heightened privacy and transparency, and aseamless experience for individuals.
Many of those problems are technical, and some involve agreement on user experience and education.
But the remaining challenges all fall into policy – the business, legal, and operational policies that areneeded to turn the technical solutions into full production-ready, scalable market solutions.
Designing those policy frameworks to work together – to fit with each other like Lego blocks as smoothly
as the technical pieces fit together – is the job of governance framework standards such as those underdevelopment by the Governance Stack Working Group at the ToIP Foundation. This is what provides theoverall solution architecture for the governance frameworks required for the Good Health Pass digitaltrust ecosystem.

7.3.3

Objective of this Drafting GroupThe Good Health Pass Interoperability Blueprint (GHP Blueprint) and the Good Health Pass
Ecosystem Governance Framework (GHP EGF)together provide a vision for the Good Health Pass digitaltrust ecosystem. This vision is rooted in the premise that the challenges of transitive trust across all of
the jurisdictions and stakeholders in international travel is sufficiently complex that it constitutes anecosystem of ecosystems in which each constituent ecosystem needs its own ecosystem governanceframework. The objective of this Drafting Group is to recommend how to establish this worldwide
infrastructure of collaborating governance frameworks.

7.3.4

Good Health Pass Digital Trust Architecture

The GHP EGF is a ToIP Layer 4 ecosystem governance framework developed according to the ToIP
Governance Metamodel defined by the ToIP Governance Stack Working Group. The metamodel reflects
five years of industry experience about the categories of policies needed to support transitive trust within
and across multiple digital trust ecosystems – the same kind of trust that we exercise constantly in legal,business, and social relationships in the real world. Development of ecosystem governance frameworks
based on the ToIP governance metamodel also follows best practices developed by the ToIP Ecosystem
Foundry Working Group.
The GHP EGF plays a special role in the Good Health Pass digital trust ecosystem: it is a general
ecosystem governance framework (general EGF) that specifies the requirements for any number of
specific ecosystem governance frameworks (specific EGFs) that serve different trust communities within
the overall ecosystem. It is very important to note that this is not a hierarchical “delegation” relationship.
A general EGF is simply a “class” that defines the overall requirements for all of the “instances” just like allclass/instance relationships as shown in Figure 18.

The Good Health Pass Interoperability Blueprint

114

Figure 18: Class/instance relationships are inheritance, not hierarchy
In any large digital trust ecosystem, the stakeholders can follow this class/instance pattern tocollaboratively develop a general EGF as their “class”, and then all of the stakeholders can develop theirown specific EGF as an “instance” as shown in Figure 19.

Figure 19: The class/instance relationships of general and specific EGFs
Applying this ecosystem of ecosystems governance framework architecture to the Good Health Pass
digital trust ecosystem yields the governance framework relationships in Figure 20.

The Good Health Pass Interoperability Blueprint

115

Figure 20: The relationship of the GHP EGF as a general ecosystem governanceframework and the specific EGFs that conform to it
Each specific EGF is developed, published, and maintained by a specific governing authority to meet therequirements of a specific jurisdiction, industry, or other trust community. This architecture embraces
local law, culture, and diversity while still enabling interoperability and transitive trust across the overall
ecosystem.
Again, the relationship of the GHP EGF as a general EGF to the GHP-compliant specific EGFs is not ahierarchical delegation relationship. In other words, the governing authority for the GHP EGF does nothave any direct authority over the governing authorities for each of the specific EGFs. Rather the only
power the general EGF governing authority has is to make revisions to the general EGF. As these revisions
are made, each of the specific EGF governing authorities can make their own decisions about complying
with those revisions if they have sufficient incentive to continue to maintain interoperability across theecosystem of ecosystems.

7.3.5

The Short Term: Self-Asserted Conformance of Specific
Governance Frameworks

The COVID-19 landscape continues to evolve very quickly. Different countries are constantly adjusting
their calculus between restrictions and reopening, carefully weighing tradeoffs between publichealth concerns and economic needs. To maximize the immediate relevance of GHP governancerecommendations in this rapidly evolving landscape, we recommend the following first steps:
1. The Good Health Pass Collaborative (GHPC) SHOULD serve as the short-term Governing Authority
for the GHP EGF.
2. The GHPC SHOULD work as quickly as possible to develop and publish an GHP EGF V1 that defines
a simple, straightforward process by which governing authorities for specific EGFs can publicly selfassert conformance with the GHP EGF V1.
3. Each participating specific EGF governing authority—whether a government, an industry body,or health pass solution provider—SHOULD develop and publish its own specific EGF as soon as
possible—ideally within 30 days of the publication of the GHP Interoperability Blueprint V1.
4. Each participating specific EGF SHOULD follow the self-assertion process defined in the GHP EGF
V1 to self-assert conformance.

The Good Health Pass Interoperability Blueprint1167.3.6

The Longer-Term GHP Governance Framework
Development Process

In the long term, the vision of the GHP Blueprint and the GHP EGF Recommendation will require building
a community of ecosystems and parties within them committed to adopting these recommendations andcreating GHP-compliant solutions. It will also require forming an official governing authority for the GHP
EGF whose job is to:
1. Complete and approve the official first version of the GHP EGF derived from the EGF
Recommendation.
2. Publish and maintain a dedicated website hosting the official GHP EGF documents.
3. Gather feedback and develop future versions based on the “in-the-field” experience of implementing
V1 as well as changes in other external factors such as regulations and health authority guidelines.
In keeping with the principles of good governance, the Governance Framework drafting group
recommends that the GHP governing authority eventually be formed and governed by the primary
stakeholders in the GHP digital trust ecosystem. For purposes of this document, we will refer to the official
governing authority resulting from this process as the GHP Foundation. However in the short term werecommend that the process of bootstrapping the GHP Foundation be the responsibility of the Good
Health Pass Collaborative (GHPC), both as defined in the previous section and in the recommendations
that follow.

7.3.6.1

Stages of EGF Development

Based on the input of the ToIP Governance Stack Working Group and the IEEE 2145 Blockchain
Governance Standards Working Group, both of whose members participated in the GHP Governance
Framework drafting group, we RECOMMEND the following bootstrap process:1. Initially, the GHPC will serve as an interim EGF governing authority responsible for stewardshipof development of the GHP EGF, and convening the first set of governing authorities committing to
implement the GHP EGF.
2. These governing authorities will implement the GHP EGF by creating their specific EGFs in
conformance with the requirements of the GHP EGF Recommendation. Each of them will build andsupport their community of participating stakeholders (issuers, verifiers and auditors) under their
EGF.
3. If there is sufficient demand for longer-term governance, these governing authorities will formallyorganize to create the GHP Foundation for long term governance of the GHP EGF. The GHP
Foundation will develop the governance policies for the GHP Foundation itself – for example,
requirements for who can join the GHP Foundation, who is authorized to make decisions about
membership, and approval of the deliverables such as new versions of the GHP EGF.) The GHP
Foundation will also be entrusted to grow the GHP Foundation membership of participating specific
EGF governing authorities.
4. The GHP Foundation will approve the official GHP EGF V1, maintain subsequent versions, andsupport the GHP Foundation members as they continue to implement the GHP EGF and create their
specific EGFs.
Figure 21 shows the progression across four stages of development and the division of responsibilities at
each stage between GHPC, the specific governing authorities who represent the primary stakeholders
creating specific EGFs, and the GHP Foundation that will take on the long-term governance of the GHP
ecosystem and deliverables.

The Good Health Pass Interoperability Blueprint117

Short-term GHP General EGF
Governance

1

GHPC(vision + initial
setup, to promote
globalinteroperability)

3

GHP Blueprint + EGF

GHP Foundation Organizational
Governance (OGF)

GHP Foundation(adopts GHPC
vision)Foundation
Rules (membership,decision making,coordination etc.)

Specific EGF Governance2

GHP Reviewers(certify that theimplementation is
GHP compliant)Auditors

GHP Implementers(GAs) (create a GHP
compliant solution +SEGF)Specific EGF

Governing
Authority

Issuers, Verifiers

Changes

Changes

GHP Updaters(manage changes,
risks, issues andupdate blueprint)

Governing
Authority
Participate in
GHP trust ecosystem(GHP Foundation)

4

Long term GHP General EGF
Governance

GHP Foundation
Auditors

GHP Foundation
members

GHP Foundation(formally approves
EGF)

GHP Blueprint +EGF

GHP Foundation(monitor and audit
solution)

GHP Foundation
members - GAs(implement
solution)

Changes

Changes

GHP Foundation
Decision makers

GHP Foundation(changemanagement,
stewardship)

A foundation of Governing Authorities committed to GHP Digital Trust ecosystem. The early
adopters may decide the rules of participation in the foundation, support the members andchange management for the blueprint and EGF (Similar to Ethereum foundation).

Figure 21: The four stages of development of governance for the Good Health Pass
digital trust ecosystem

7.3.7

Recommendations

Following are specific recommendations for progressing through each of the four stages.

7.3.7.1

Stage 1: Initial GHP General EGF Governance

1. GPHC SHALL publish the GHP Blueprint and GHP EGF Recommendations.
2. Simultaneously, GHPC SHALL invite specific governing authorities to participate in theestablishment of the GHP Foundation and create their specific EGFs.
3. GHPC SHALL assist in onboarding the participating governing authorities as early adopters andfacilitate coordination and collaboration amongst them.
4. Specific governing authorities SHALL comply with the GHP Blueprint and GHP EGF
Recommendations to create GHP-compliant specific EGFs.
4.1. GHPC SHOULD support these early adopters to help establish baselines and benchmarks forthe global ecosystem.
5. Specific governing authorities MUST self-attest their compliance with the GHP EGF
Recommendations.
5.1. GHPC SHOULD review the self-attestations and certify compliance.
6. Specific governing authorities MAY report issues faced during the implementation and proposechanges to the GHP EGF.

The Good Health Pass Interoperability Blueprint118

6.1. GHPC SHOULD adopt proposed changes judged to be beneficial to the Good Health Pass
digital trust ecosystem.

7.3.7.2

Stage 2: Specific EGF Governance

1. Participating specific governing authorities MUST complete their V1 specific EGFs in compliancewith the requirements in the GHP EGF.
2. Governed actors such as issuers, verifiers, and trust registries participating in a specific EGF
SHOULD complete their implementations in compliance with the GHP EGF.
2.1. The governing authority SHOULD establish a support structure to assist the governed actors.
3. If the specific EGF specifies conformance auditing:
3.1. The governing authority MUST appoint auditors meeting the requirements in the specific EGF.
3.2. Auditors MUST perform the audit function for a governed party as specified by the trust
assurance framework.
3.3. If a governed party is in compliance, the auditor MUST provide an attestation of complianceas specified by trust assurance framework.
3.4. If the governed party is not in compliance, the governed party MUST remediate noncompliances in accordance with the trust assurance framework.
4. Revisions to the EGF MAY be made for any of the following reasons:4.1. Governed parties raise risks, issues, or improvements.
4.2. Changes due to external factors such as new regulations.
4.3. Changes due to a revision of the GHP EGF.
5. Governing authorities SHOULD create a Risk/Change Management Board or similar governing bodyto address risks, issues and changes to its specific EGF.

7.3.7.3

Stage 3: Formation of the GHP Foundation

1. Participating governing authorities MUST formally organize and create the GHP Foundation.
2. The GHP Foundation MUST replace the GHPC’s interim governance role and take on the following
responsibilities:
2.1. Building a strong GHP digital trust ecosystem of ecosystems.
2.2. Administering and revising the GHP EGF, including monitoring and revising governance of the
GHP Foundation itself.

7.3.7.4

Stage 4: Ongoing GHP EGF Governance

1. Once it is officially established, the GHP Foundation MUST:
1.1. Onboard initial members.
1.2. Approve the GHP Ecosystem Governance Framework V1.
2. The GHP Foundation SHOULD provide support for members implementing GHP-compliant specific
EGF.
3. The GHP Foundation SHOULD perform a risk assessment and generate a risk treatment plan toaddress identified risks.
4. The GHP Foundation SHOULD establish a certification process for GHP-compliant specific EGF aspart of the trust assurance framework of the GHP EGF.
4.1. The trust assurance framework SHOULD include a trust mark.

The Good Health Pass Interoperability Blueprint1194.2. This process MAY include self-attestation.
5. The GHP Foundation SHOULD follow a change management process to review proposed changes,
assess the impact and make revisions to the EGF, if necessary.

7.3.8

Governance Matrix for the EGF Development

The four stage GHP EGF development process above shows multiple parties collaborating at each stage
to meet the objectives. To facilitate governance decisions across these stages, we are recommending
the Governance Matrix tool created by the IEEE P2145 Blockchain Governance group (see below).
The Governance Matrix shows the governance considerations (down) that need to be addressed acrossdifferent stages of an ecosystem’s lifecycle (across).
The governance considerations include the key questions about who is being governed (governed
parties), who governs (governing authorities), process of governance (how decisions get made), andincentives and accountability. Each of these can be different at each stage.
The GHPC has used the Governance Matrix in development of our initial governance recommendations
during the initial stage. The Matrix can be used in similar fashion for subsequent stages.

The Good Health Pass Interoperability Blueprint120

Governance Dimensions

Governance Framework (GF)

Defition: Governance is about decision making for direction and control
of a dynamic system

Governance for the Governance Framework Development lifecycle.

Governance Considerations

Envision EGF

Business need / Purpose- Create a globallyinteroperable ToIP
Layer 4 digital trust
ecosystem that operates
according to the Good
Health Pass Principles.
Please refer to Good
Health Pass Ecosystem
Governance Framework
Recommendation
for scope, objectives,principles andrequirements.

Execute EGF

Enhance EGF

short-term - setup (build
community of early
adopters)

medium-term - create(early adopters create
governing authority)

long-term - operate(govenrning authority
operational)

Implement - Invite
Governing Authorities toimplement the EGF (theparticipating authorities/
early adopters will create
the SEGF based on General
EGF); Provide support for
and review of the early
implementations; Changemangement for EGF

GHP Foundation
formation - Early adopters
collaborate to form the
GHP Foundation, define theorganizational governancefor the GHP.

GHP Foundation
operational - GHP
Foundation becomes
official Governing Authority
for the GHP EGF, andassumes the role ofsupporting and auditing
GHP compliant solutions,maintaining EGF, risks andissues.

GHP Foundation change
management - Identify
issues, accept andprocess change proposals,considering the impact ofchange, communication
and adoption of change
etc.

Governance Structure
Who is involved in Governance?
Members
Who are the members? Governed members/ Governing Authority?
Decision makers (Governance Authority)
Who are decision makers? What is the structure of decision making team (if it is a team)? Centralized, Federated,
Decentralized?
Organization
How are the members organized? Are there any formal / informal communities (e.g., Working groups,
committees)?
Governance Process
How do members work together to make Governance decisions (policies)?
Membership
What is the process for membership management, communities / decision making bodies memberships?
Communication / Coordination
How communities communicate / coordinate? What tools/processes they use?
Decision making
What is the process of decision making (including decisions for memberships, scope, objectives, deliverables, andany other unanticipated decisions)?
Governance Decisions
What are the outcomes (deliverables) of Governing process? What decisions (rules, policies or other) are made? Where
are they published? (this will depend on what the Governance is for)Incentives / Accountability
What are available incentives for different roles?
Financial
Are there financial incentives? (for example cost reduction with compliance or increased costs with noncompliance)
SocialAre there social incentives such as social recognition or other?

Figure 22: Governance Matrix
The Good Health Pass Interoperability Blueprint –121

Appendices

The Good Health Pass Interoperability Blueprint

122

References
About the Semantics Of Business Vocabulary And Business Rules Specification Version 1.5
https://www.omg.org/spec/SBVR
Accreditation - Wikipedia
https://en.wikipedia.org/wiki/Accreditation
Adopt | Human Colossus Foundation
https://wiki.colossi.network/en/Technologies/OCA/Developer/Adopt
Airport Health Testing and Travel Information Standard - APIs
https://acris.aero/api-travel-health-information-standard/
Apache License, Version 2.0
http://www.apache.org/licenses/LICENSE-2.0.html
Audit - Wikipedia
https://en.wikipedia.org/wiki/Audit
Barcode - Wikipedia
https://en.wikipedia.org/w/index.php?title=Barcode&oldid=1016784379
BBS+ Signatures 2020
https://w3c-ccg.github.io/ldp-bbs2020/
Biometric passport - Wikipedia
https://en.wikipedia.org/wiki/Biometric_passport
Business logic - Wikipedia
https://en.wikipedia.org/wiki/Business_logic
Business rules engine - Wikipedia
https://en.wikipedia.org/w/index.php?title=Business_rules_engine&oldid=923067160
Call for public comments: Interim guidance for developing a Smart Vaccination Certificate – Release
Candidate 1
https://www.who.int/news-room/articles-detail/call-for-public-comments-interim-guidance-fordeveloping-a- smart-vaccination-certificate-release-candidate-1
CCCC4
https://cccc4.ca/
CCI Schema Reference Documents
https://drive.google.com/drive/u/1/folders/1h4vF79KzUY6KipBt3A6kMEboiqcSYtv7
Certification - Wikipedia
https://en.wikipedia.org/w/index.php?title=Certification&oldid=1005115412
Consent Receipt Specification – Kantara Initiative
https://kantarainitiative.org/download/7902/
Core data set for the Smart Vaccination Certificate
https://www.who.int/publications/m/item/core-data-set-for-the-smart-vaccination-certificate
Coronavirus (COVID-19) - NHS
https://www.nhs.uk/conditions/coronavirus-covid-19/

The Good Health Pass Interoperability Blueprint123

Coronavirus (COVID-19) testing before you travel to Englandhttps://www.gov.uk/guidance/coronavirus-covid-19-testing-for-people-travelling-to-england
Coronavirus (COVID-19) vaccine - NHS
https://www.nhs.uk/conditions/coronavirus-covid-19/coronavirus-vaccination/coronavirus-vaccine/Coronavirus disease (COVID-19)
https://www.who.int/emergencies/diseases/novel-coronavirus-2019
COVID-19 Credentials initiative
https://www.covidcreds.org
COVID-19 Response and Recovery Platform
https://www.icao.int/covid/Pages/default.aspx
COVID-19: Digital COVID certificates | European Commission
https://ec.europa.eu/info/live-work-travel-eu/coronavirus-response/safe-covid-19-vaccineseuropeans/covi d-19-digital-green-certificates_en
COVID-19 Vaccination - Clinical Resources for Each COVID-19 Vaccine
https://www.cdc.gov/vaccines/covid-19
Creative Commons — Attribution 4.0 International — CC BY 4.0
https://creativecommons.org/licenses/by/4.0/
Credentials Community Grouphttps://www.w3.org/groups/cg/credentials
Cryptographic hash function - Wikipedia
https://en.wikipedia.org/wiki/Cryptographic_hash_function
Cybersecurity Best Practices
https://www.cisecurity.org/cybersecurity-best-practices/
Decentralized Identifiers (DIDs) v1.0
https://www.w3.org/TR/did-core/
Decision support system - Wikipedia https://en.wikipedia.org/w/index.php?title=Decision_support_system&oldid=1009221582
Decision-making - Wikipedia
https://en.wikipedia.org/wiki/Decision-making
DIF Presentation Exchange
https://identity.foundation/presentation-exchange/
Digital Identity and Federation in Health Care
https://www.carinalliance.com/wp-content/uploads/2020/12/LPCA_CARIN-Alliance-FederatedTrust-Agre ement_FINAL-12.3.2020.pdf
Digital signature - Wikipedia
https://en.wikipedia.org/wiki/Digital_signature
Dispute resolution - Wikipedia
https://en.wikipedia.org/w/index.php?title=Dispute_resolution&oldid=1015333922
DIVOC - Digital Infrastructure for Vaccination Open Credentialing
https://divoc.egov.org.in/

The Good Health Pass Interoperability Blueprint124

Ecosystem Foundry Working Grouphttps://wiki.trustoverip.org/display/HOME/Ecosystem+Foundry+Working+GroupeHealth and COVID-19 | Public Healthhttps://ec.europa.eu/health/ehealth/covid-19_en
eHealth Network - Guidelines on COVID-19 citizen recovery interoperable certificates - minimum dataset
https://ec.europa.eu/health/sites/health/files/ehealth/docs/citizen_recovery-interoperablecertificates_en.p df
eHealth Network - Guidelines on Value Sets for Digital COVID Certificateshttps://ec.europa.eu/health/sites/health/files/ehealth/docs/digital-green-certificates_dtspecifications_en.p df
eHealth Network - Guidelines on verifiable vaccination certificates - basic interoperability elements
https://ec.europa.eu/health/sites/health/files/ehealth/docs/vaccination-proof_interoperabilityguidelines_en.pdf
eHealth Network | Public Healthhttps://ec.europa.eu/health/ehealth/policy/network_en
eSSIF-Lab Glossary
https://essif-lab.pages.grnet.gr/framework/docs/essifLab-glossary
EU health preparedness: a common list of COVID-19 rapid antigen tests, including those of which theirtest results are mutually recognised, and a common standardised set of data to be included in COVID-19
test result certificateshttps://ec.europa.eu/health/sites/health/files/preparedness_response/docs/covid-19_rat_commonlist_en. pdf
EUR-Lex - 52021PC0130 - EN - EUR-Lex
https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:52021PC0130
FHIR v4.0.1
http://hl7.org/fhir/
FHIR Focus Grouphttps://wiki.trustoverip.org/display/HOME/FHIR+Focus+Group
General Data Protection Regulation (GDPR) Compliance Guidelines
https://gdpr.eu/
General Data Protection Regulation - Wikipedia
https://en.wikipedia.org/wiki/General_Data_Protection_Regulation
Global Reference Docs
https://drive.google.com/drive/u/1/folders/1y-nr-YlacLvv7P54N6EUYVrBNt7YA51T
Good Health Pass - A Safe Path to Global Reopening
https://www.goodhealthpass.org/wp-content/uploads/2021/02/Good-Health-Pass-CollaborativePrinciples- Paper.pdf
Good Health Pass Collaborative
https://www.goodhealthpass.org/
Good Health Pass Working Grouphttps://wiki.trustoverip.org/pages/viewpage.action?pageId=73790

The Good Health Pass Interoperability Blueprint

125

Governance Framework-GHP-Execution
https://docs.google.com/spreadsheets/d/18WVtpVcyyh2NDsvi48FkxtbXKf49c62d/edit
Governance Stack Working Grouphttps://wiki.trustoverip.org/display/HOME/Governance+Stack+Working+GroupGS1 2D Barcode Verification Process Implementation Guideline
https://www.gs1.org/docs/barcodes/2D_Barcode_Verification_Process_Implementation_Guideline.
pdf
Guidance on Levels of Assurance
https://ec.europa.eu/cefdigital/wiki/download/attachments/40044784/
Guidance+on+Levels+of+Assurance. docx
Health Level Seven International - Wikipedia
https://en.wikipedia.org/wiki/Health_Level_Seven_International
How to prove and verify someone’s identity
https://www.gov.uk/government/publications/identity-proofing-and-verification-of-an-individual
How to register with a GP surgery - NHS
https://www.nhs.uk/nhs-services/gps/how-to-register-with-a-gp-surgery/
IATA - COVID-19: All resources
https://www.iata.org/en/programs/covid-19-resources-guidelines/
IATA - Travel Pass Initiative
https://www.iata.org/en/programs/passenger/travel-pass/
ICAO
https://icao.int/
ICE — Immunization Calculation Engine
https://cdsframework.atlassian.net/wiki/spaces/ICE/overview
ICTS TravelDoc Immigration Rules
https://www.traveldoc.aero/
ICTS TravelDoc Health Rules
https://infopages.traveldoc.aero/Information/Coronavirus
ID2020 | Digital Identity Alliancehttps://id2020.org/
Importing CSV data into a FHIR server | Hay on FHIR
https://fhirblog.com/2019/03/25/importing-csv-data-into-a-fhir-server/
Information Commissioner’s Officehttps://ico.org.uk/for-organisations/guide-to-the-general-data-protection-regulation-gdpr/
individual-rights/ri ght-to-rectification/
Information system - Wikipedia
https://en.wikipedia.org/wiki/Information_systems
Interim guidance for developing a Smart Vaccination Certificate
https://www.who.int/publications/m/item/interim-guidance-for-developing-a-smart-vaccinationcertificate

The Good Health Pass Interoperability Blueprint

126

Interoperability - Wikipedia
https://en.wikipedia.org/wiki/Interoperability
Interoperability in Healthcare | HIMSS
https://www.himss.org/resources/interoperability-healthcare
Introducting the Trust Over IP Foundation
https://trustoverip.org/resources/intro-to-toip/
ISO - ISO 17442:2012 - Financial services — Legal Entity Identifier (LEI)
https://www.iso.org/standard/59771.html
ISO - ISO/IEC 18004:2015 - Information technology — Automatic identification and data capture
techniques — QR Code bar code symbology specification
https://www.iso.org/standard/62021.html
ISO - ISO/IEC 29115:2013 - Information technology — Security techniques — Entity authentication
assurance framework
https://www.iso.org/standard/45138.html
ISO Online Browsing Platform
https://www.iso.org/obp/ui/
ISO/IEC 18013-5 mdoc for eHealth - Internationally standardized protocols for vaccination certificateshttps://github.com/18013-5/micov/blob/main/ISO_IEC_18013_5_for_eHealth.pdf
Joint Development Foundation
https://www.jointdevelopment.org/
JSON Schema | The home of JSON Schemahttps://json-schema.org/
JSON-LD 1.1
https://json-ld.org/spec/latest/json-ld/
Jurisdiction Specific Reference Docs
https://drive.google.com/drive/u/1/folders/1Gmapb1ktvm-v3NDH65AZEUJ--ouvcg
Jurisdictions
https://essif-lab.pages.grnet.gr/framework/docs/terms/pattern-jurisdiction
Legal Entity Identifier - Wikipedia
https://en.wikipedia.org/w/index.php?title=Legal_Entity_Identifier&oldid=1016164326
Linked Data Proofs 1.0
https://w3c-ccg.github.io/ld-proofs/
Linux Foundation - Decentralized innovation, built with trust
https://www.linuxfoundation.org/
Linux Foundation Public Health – Collaborating to battle COVID
https://www.lfph.io
Machine Reaadable Travel Documents - Technical Report - VDS-NC - Visible Digital Seal for nonconstrained environments
https://www.icao.int/Security/FAL/TRIP/PublishingImages/Pages/Publications/Visible%20
Digital%20Seal%20for%20non-constrained%20environments.pdf

The Good Health Pass Interoperability Blueprint

127

Machine-readable data - Wikipedia
https://en.wikipedia.org/wiki/Machine-readable_data
NIST SP 800-63 Digital Identity Guidelines
https://pages.nist.gov/800-63-3/
NIST Special Publication 800-63A
https://pages.nist.gov/800-63-3/sp800-63a.html
NIST Special Publication 800-63A - Digital Identity Guidelines - Enrollment and Identity Proofing
https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-63a.pdf
NIST Special Publication 800-63B
https://pages.nist.gov/800-63-3/sp800-63b.html
NIST Special Publication 800-63B - Digital Identity Guidelines - Authentication and Lifecycle Management
https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-63b.pdf
NOTAM - Wikipedia
https://en.wikipedia.org/wiki/NOTAM
oca-fhir-cli
https://github.com/SemanticClarity/oca-fhir-cli
On an innovative architecture for digital immunity passports and vaccination certificateshttps://arxiv.org/ftp/arxiv/papers/2103/2103.04142.pdf
OpenID Connect | OpenID
https://openid.net/connect/
Overlays Capture Architecture — The Human Colossus Foundation
https://humancolossus.foundation/blog/cjzegoi58xgpfzwxyrqlroy48dihwz
P2145 - Standard for Framework and Definitions for Blockchain Governancehttps://standards.ieee.org/project/2145.html
P2145 Blockchain Governance Standards Working Group - IEEE 2145
https://sagroups.ieee.org/ieee2145/
Parties, Actors and Actions
https://essif-lab.pages.grnet.gr/framework/docs/terms/pattern-party-actor-action
Permalink - Wikipedia
https://en.wikipedia.org/wiki/Permalink
Personhood - Wikipedia https://en.wikipedia.org/wiki/Personhood
Privacy by design - Wikipedia
https://en.wikipedia.org/wiki/Privacy_by_design
Protected health information - Wikipedia
https://en.wikipedia.org/w/index.php?title=Protected_health_information&oldid=1023641320
Public key certificate - Wikipedia
https://en.wikipedia.org/w/index.php?title=Public_key_certificate&oldid=1018062037
Public key infrastructure - Wikipedia
https://en.wikipedia.org/wiki/Public_key_infrastructure

The Good Health Pass Interoperability Blueprint128

QR code - Wikipedia
https://en.wikipedia.org/w/index.php?title=QR_code&oldid=1020475188
RDF 1.1 Concepts and Abstract Syntax
https://www.w3.org/TR/rdf11-concepts/
Requirement for Proof of Negative COVID-19 Test or Recovery from COVID-19 for All Air Passengers
Arriving in the United States | CDC
https://www.cdc.gov/coronavirus/2019-ncov/travelers/testing-international-air-travelers.html
RFC 2119 - Key words for use in RFCs to Indicate Requirement Levels
https://tools.ietf.org/html/rfc2119
RFC 3986 - Uniform Resource Identifier (URI): Generic Syntax
https://tools.ietf.org/html/rfc3986
RFC 4648 - The Base16, Base32, and Base64 Data Encodings
https://tools.ietf.org/html/rfc4648
Secure by design - Wikipedia
https://en.wikipedia.org/wiki/Secure_by_design
Self-declare as a private COVID-19 testing provider
https://www.gov.uk/guidance/self-declare-as-a-private-sector-covid-19-testing-provider
Self-Issued OpenID Connect Provider DID Profile v0.1
https://identity.foundation/did-siop/
Semantic Domain - Trust Over IP
https://trustoverip.org/working-groups/decentralized-semantics/
SMART Health Cards Framework
https://smarthealth.cards/
Smart Vaccination Certificate Working Grouphttps://www.who.int/groups/smart-vaccination-certificate-working-group
Software system - Wikipedia
https://en.wikipedia.org/wiki/Software_system
Technical Standards &amp; Reporting: COVID-19 Vaccination | CDC
https://www.cdc.gov/vaccines/covid-19/reporting/requirements/index.html
Testing for coronavirus (COVID-19) - NHS
https://www.nhs.uk/conditions/coronavirus-covid-19/testing/
The FAIR Guiding Principles for scientific data management and stewardshiphttps://www.nature.com/articles/sdata201618
The Trusted Digital Identity Framework | Digital Transformation Agency
https://www.dta.gov.au/our-projects/digital-identity/trusted-digital-identity-framework
ToIP Governance Metamodel - Home - Confluence
https://wiki.trustoverip.org/display/HOME/ToIP+Governance+Metamodel
Trust Framework | Digital ID & Authentication Council of Canada
https://diacc.ca/trust-framework/

The Good Health Pass Interoperability Blueprint

129

Trust Over IP - Defining a complete architecture for Internet-scale digital trust
https://trustoverip.org/
Trusted execution environment - Wikipedia
https://en.wikipedia.org/wiki/Trusted_execution_environment
Vaccination Certificate Vocabulary v0.1
https://w3c-ccg.github.io/vaccination-vocab/
VCI
https://vci.org/
Verifiable Credentials Data Model 1.0
https://www.w3.org/TR/vc-data-model/
W3C Patent Policy
https://www.w3.org/Consortium/Patent-Policy-20040205
Wallet And Credential Interactions
https://identity.foundation/waci-presentation-exchange/
World Wide Web Consortium (W3C)
http://www.w3.org/
X.509 - Wikipedia
https://en.wikipedia.org/wiki/X.509
Zero-knowledge proof - Wikipedia
https://en.wikipedia.org/wiki/Zero-knowledge_proof

The Good Health Pass Interoperability Blueprint

130

Glossary
Purpose and Scope
The purpose of this glossary is to support the recommendations of the Interoperability Working Groupfor Good Health Pass hosted by the ToIP Foundation and the Good Health Pass Collaborative hosted by
ID2020. It includes the most relevant terms from related glossaries including:z W3C Verifiable Credentials Data Model 1.0
z W3C Decentralized Identifiers (DIDs) 1.0
z W3C CCG JSON-LD 1.1
z W3C CCG Linked Data Proofs 1.0
z eSSIF-Lab Glossaryz EU General Data Protection Regulation (GDPR)z HIMSS Healthcare Interoperability
The scope of this glossary is terms that are required to enable interoperable implementations of thesoftware and systems required by issuers, holders, and verifiers of GHP-compliant health passes
together with the governing authorities and governance frameworks under which these parties will beinteroperating. Within this scope, unless explicitly declared otherwise, terms defined in this glossary are
only used in the meaning provided herein. Outside of this scope, these terms may have other meanings.

Formatting
1. Terms that are used, and whose meaning is defined in this glossary, and whose meaning is includedin this glossary, appear in bold. When a term that is defined in this glossary appears as regular text
(not bolded), it is to be interpreted as usual (e.g. according to well-known dictionaries).
2. In some cases, where a term is imported from another scope, its definition will use supporting terms
that are hyperlinked to their definitions in that scope. Those hyperlinks have only been replaced withterms in bold only if the supporting term is included in this glossary.
3. The definition of terms imported from other scopes are prefixed with the name of that scope (anda link where applicable). All terms defined in the scope of this glossary are prefixed with “(GHPGlossary)”.
4. If a term is cited from Wikipedia, the link is the Wikipedia permalink.
5. If a term is used in more than one scope that applies to the Good Health Pass digital trust
ecosystem, multiple definitions are shown. The authoritative definition in the context of thisglossary is the one prefixed with “(GHP Glossary)”.

Terms
1-way paper credential(GHP Glossary) A paper credential that is either issued directly to the holder orgenerated from a digital credential in such a way that it is not possible to transform itback into the original digital credential without contacting the issuer for re-issuance.

1-way paper pass
(GHP Glossary) A paper pass that is either issued directly to the holder or generated from a digital pass

The Good Health Pass Interoperability Blueprint131

in such a way that it is not possible to transform it back into the original digital pass without contacting
the issuer for re-issuance.

2-way paper credential(GHP Glossary) A paper credential generated from a digital credential in such a way that it can belosslessly transformed back into the original digital credential by following a published algorithm.

2-way paper pass
(GHP Glossary) A paper pass generated from a digital pass in such a way that it can be losslesslytransformed back into the original digital pass by following a published algorithm.

AAL(ToIP Governance) Abbreviation for authenticator assurance level.

actor(ESSIF Lab Glossary) An entity that can act (do things), e.g. people, machines, but not organizations. See
the eSSIF-Labs Parties, Actors, and Actions pattern for more information.

administering authority(ToIP Governance) The party responsible for administering a particular governance framework. The
administering authority may or may not be the governing authority. For example, an NGO may be
the administering authority for a governance framework governed by a government as the governing
authority.

anti-correlation(ToIP Glossary) A technique for privacy preservation that eliminates any unnecessary correlators froma message and its data payload, such as a credential. Anti-correlation applies specifically to digital
cryptography, where public keys and digital signatures can serve as globally unique identifiers for the
subject and/or holder. One solution for this type of anti-correlation is to use zero-knowledge

proof cryptography.

attestation(ToIP Glossary) A set of data asserted about a subject for which the attester can be held accountable. This
includes a self-attestation from the subject itself.

auditor(ToIP Governance) A person or legal entity that assesses the conformance of a governed party to therequirements of a governance framework. The auditor may itself be required to follow the requirementsof a trust assurance framework.

auditor accreditor(ToIP Governance) A certifying party for auditors.

authentication(W3C Decentralized Identifiers 1.0) Authentication is a process by which an entity can prove it has a
specific attribute or controls a specific secret using one or more verification methods. For example, with
DIDs, a common authentication method is to prove control of the cryptographic private key associatedwith a public key published in a DID document.

authenticator assurance level (AAL)(ToIP Governance) The term is used in the NIST 800-63B standard for what the ISO/IEC 29115:2013
standard calls authentication LoA.

The Good Health Pass Interoperability Blueprint132

authentication LoA(ToIP Governance) The level of assurance achieved in an authentication event in any identity
authentication zone. For example, in zone 2 an issuer can assign an authentication LoA based on thestrength of authenticating the holder against the available identity binding data at the time of issuing
acredential or pass. In zone 3 a verifier can assign an authentication LoA based on the strength ofauthenticating the holder against the same identity binding data. Note that the verifier’s authentication
LoA cannot exceed the issuer’s authentication LoA. Note: This term is from the ISO/IEC 29115:2013
standard; the NIST 800-63B standard uses the term authentication assurance level (AAL).

authoritative issuer(ToIP Glossary) An issuer that is either inherently trusted by some set of verifiers (for example, a trusted
government agency) or that has been explicitly authorized by a governing authority in a governanceframework to issue one or more verifiable credential types. Authoritative issuers are often listed in atrust registry controlled by the governing authority.

authority(ESSIF Lab Glossary) a party of which certain decisions, ideas, rules etc. are followed by other parties. A
centralized authority uses its powers to further its own objectives by imposing its decisions, ideas, rules
etc. on other parties. A decentralized authority uses its power to further the objectives of the parties thathave given it these powers of their free will as they find it beneficial for themselves to do so. An authority
can be anywhere in this spectrum.

barcode(Wikipedia) A method of representing data in a visual, machine-readable form.

base32URL(GHP Glossary) Base32URL is used to represent a Base32 encoding (https://tools.ietf.org/html/
rfc4648) without the padding (‘=’), which is not a character of the Alphanumeric QR alphabet. The use of
the suffix“URL” matches the technique used for the Base64URL variation.

business rule
(ToIP Governance) A rule that is under business jurisdiction, and is used to express business logic. For
details, see the Semantics of Business Vocabulary and Business Rules (SBVR) standard from the Object
Management Group.

CA(Wikipedia) Abbreviation for certificate authority.

card(GHP Glossary) The physical object on which a QR credential is printed. A card can enhance thecryptographic security or reduce the needs for stronger cryptographic securities by including physicalsecurity features to avoid counterfeiting and cloning. Although the term “card” is used in a Good HealthPass context, a QR credential can also be printed on a booklet, a label, a sticker, or any other physicalmedium.
(Smart Health Cards) A synonym for a digital credential that uses the metaphor of a physical card suchas a credit card, business card, or health insurance card. See Smart Health Card. A card is not a synonym
for a pass.

certificate(GHP Glossary) A set of data asserted about a subject by an issuer that can be verified in some manner,
either manually or automatically. A credential is a type of certificate, and a pass is a type of credential.
See also health certificate.

The Good Health Pass Interoperability Blueprint133

In the context of Public Key Infrastructure (PKI), a public key certificate or X509 certificate is adigitallysigned structured document binding the subject’s public key to one or more identifiers for the
subject. The signer is usually a certificate authority, however a certificate may also be self-signed.

certificate authority (CA)(ToIP Glossary) The legal entity responsible for issuing a public key certificate.

certificate chain(ToIP Glossary) See X.509 certificate chain.

certification(Wikipedia) The formal attestation or confirmation of certain characteristics of an object, person, ororganization. This confirmation is often, but not always, provided by some form of external review,education, assessment, or audit. Accreditation is a specific organization’s process of certification.
(GHP Glossary) The process that a certifying party performs to assess conformance of a governed
party to the requirements of a governance framework. The certification process follows the policies andprocedures defined in a trust assurance framework.

certification body
(ToIP Governance) A governed party that performs certification.

claim(W3C Verifiable Credentials Data Model 1.0) An assertion made about a subject.
(ToIP Glossary) An assertion about a subject made within the context of a verifiable credential. Also
known as an attribute or property of the subject.

consent(ToIP Governance) Permission granted by a subject for some set of the subject’s personal data to beprocessed by another party. Under Article 7 of the EU General Data Protection Regulation (GDPR),
consent must be freely given, specific, informed, and unambiguous.

consent receipt(ToIP Governance) A verifiable record of the granting of consent by a subject. See the Kantara Consent
Receipt Specification.

controlled document(ToIP Glossary) A component document of a governance framework that follows the modular
architecture of the ToIP governance metamodel. All controlled documents must be listed in the primary
document.

credential(GHP Glossary) A certificate issued in a form designed to be easily transported by the holder and easily
verified by a verifier, especially using machine-readable data and/or cryptographic signatures. In mostcases a credential also uses one or more identity bindings that enable a verifier to authenticate thesubject and/or holder. A credential may be either a paper credential or a digital credential. Either form
may be a verifiable credential according to various standards, including the W3C Verifiable Credentials
Data Model 1.0. See also health credential, identity credential, and card. A pass is a specific type ofcredential.
(W3C Verifiable Credentials Data Model 1.0) A set of one or more claims made by an issuer. See also
verifiable credential.

The Good Health Pass Interoperability Blueprint134custodial wallet(ToIP Glossary) A digital wallet in which the private keys are held by a trusted third party and not directlyby the holder. The third party is called the custodian. In most cases a custodial wallet is hosted in thecloud as a service provided by the third party and accessed by the holder using a secure web browser.
Mutually exclusive with non-custodial wallet.

custodian(ToIP Glossary) A trusted third party operating a custodial wallet.

data controller(EU General Data Protection Regulation) A natural or legal person, public authority, agency, or other bodywhich, alone or jointly with others, determines the purposes and means of the processing of personal
data.

data processor(EU General Data Protection Regulation) A natural or legal person, public authority, agency, or other bodywhich processes personal data on behalf of a data controller.

data minimization(W3C Decentralized Identifiers 1.0) The act of limiting the amount of shared data strictly to the minimum
necessary to successfully accomplish a task or goal.

DDCC(World Health Organization) Abbreviation for Digital Documentation of COVID-19 Certificate.

decentralized identifier (DID)(W3C Decentralized Identifiers 1.0) A globally unique persistent identifier that does not require a
centralized registration authority and is often generated and/or registered cryptographically. The genericformat of a DID is defined in § 3.1 DID Syntax. A specific DID scheme is defined in a DID method
specification. Many—but not all—DID methods make use of distributed ledger technology (DLT) or
some other form of decentralized network.

decentralized PKI(ToIP Glossary) Public key infrastructure based on decentralized identifiers (DIDs).

decision support system (DSS)(Wikipedia) An information system that supports business or organizational decision-making activities.
DSSs serve the management, operations and planning levels of an organization (usually mid and higher
management) and help people make decisions about problems that may be rapidly changing and noteasily specified in advance—i.e. unstructured and semi-structured decision problems. Decision support
systems can be either fully computerized or human-powered, or a combination of both.
(GHP Glossary) See also rules engine.

DID(W3C Decentralized Identifiers 1.0) Abbreviation for decentralized identifier.

DID chain(ToIP Glossary) A set of DIDs linked in a hierarchical model where each DID (except the root) digitally signs
the next DID in the chain. DID chains can be verified for cryptographic trust by “walking the chain” back to
the root of trust. See also trust registry. Contrast with X.509 certificate chain.

The Good Health Pass Interoperability Blueprint

135

DID controller(W3C Decentralized Identifiers 1.0) An entity that has the capability to make changes to a DID
document. A DID might have more than one DID controller. The DID controller(s) can be denoted by the
optional controller property at the top level of the DID document. Note that a DID controller might be the
DID subject.

DID document(W3C Decentralized Identifiers 1.0) A set of data describing the DID subject, including mechanisms, suchas cryptographic public keys, that the DID subject or a DID delegate can use to authenticate itself andprove its association with the DID. A DID document might have one or more different representations as
defined in § 6. Representations or in the W3C DID Specification Registries [DID-SPEC-REGISTRIES].

DID method(W3C Decentralized Identifiers 1.0) A definition of how a specific DID method scheme is implemented.
A DID method is defined by a DID method specification, which specifies the precise operations by which
DIDs and DID documents are created, resolved, updated, and deactivated. See § 8. Methods.

DID scheme(W3C Decentralized Identifiers 1.0) The formal syntax of a decentralized identifier. The generic DID
scheme begins with the prefix did: as defined in § 3.1 DID Syntax. Each DID method specification
defines a specific DID method scheme that works with that specific DID method. In a specific DID method
scheme, the DID method name follows the first colon and terminates with the second colon, e.g.,
did:example:

DID subject(W3C Decentralized Identifiers 1.0) The entity identified by a DID and described by a DID document.
Anything can be a DID subject: person, group, organization, physical thing, digital thing, logical thing, etc.

DID URL(W3C Decentralized Identifiers 1.0) A DID plus any additional syntactic component that conforms to
the definition in § 3.2 DID URL Syntax. This includes an optional DID path (with its leading / character),
optional DID query (with its leading ? character), and optional DID fragment (with its leading # character).

dispute resolution(Wikipedia) The process of resolving disputes between parties.

distributed ledger (DLT)(W3C Decentralized Identifiers 1.0) A non-centralized system for recording events. These systems
establish sufficient confidence for participants to rely upon the data recorded by others to make
operational decisions. They typically use distributed databases where different nodes use a consensus
protocol to confirm the ordering of cryptographically signed transactions. The linking of digitally signed
transactions over time often makes the history of the ledger effectively immutable.

digital credential(ToIP Glossary) A credential in digital form that may be stored in a digital wallet. A digital credential may
be either an online credential or an offline credential. It may be stored in a high-end or low-end device,
may be transmitted from an issuer to a holder and presented from a holder to a verifier via various
protocols, including barcodes on a screen, Bluetooth API, HTTPS call, and so on. Mutually exclusive withpaper credential.

Digital Documentation of COVID-19 Certificates (DDCC)(World Health Organization) This type of health certificate, previously known as a “smart vaccination

The Good Health Pass Interoperability Blueprint136

certificate (SVC)”, was renamed in June 2021. At that time, the Smart Vaccination Certificate Secretariat
expanded the scope of the initiative to develop guidance that includes SARS-CoV-2 testing and COVID-19
recovery status. The DDCC is a medical document that records services that an individual has received.
DDCC, or cards, refer to digital records that are accessible by the person, and serve the same purposesas traditional home-based records: they provide a tool to ensure continuity of care and a proof ofservices. It can be purely digital and stored, for example, on a smartphone application or a cloud-based
server. Alternatively, it can be a “digital twin” of a traditional paper home-based record. A smartphone
is not required to have a DDCC. The link between the paper DDCC record and the digital record can beestablished by a barcode, for example, that is printed on the paper vaccination card.

digital pass
(GHP Glossary) A pass in digital form that is stored in a digital wallet app. A digital pass may be stored
statically or generated in response to a presentation request. A digital pass may also be issued directlyby
an issuer—or a rules engine acting as an issuer. See also verifiable digital pass.

digital trust ecosystem(ToIP Glossary) An ecosystem of governed parties that interoperate to achieve a set of trust objectives
online. Layer 4 of the ToIP stack is designed to support digital trust ecosystems.

digital wallet(ToIP Glossary) Software used by a holder to store the cryptographic private keys necessary to exert
control over DIDs, digital credentials of any type, and digital value stores such as cryptocurrencies.
Digital wallets are also commonly used to store digital credentials and passes issued to the holder. See
also custodial wallets and non-custodial wallets.

digital wallet app(ToIP Glossary) A mobile app used by a holder to perform the functions of a digital wallet.

DLT(ToIP Glossary) Abbreviation for distributed ledger technology.

DSS(Wikipedia) Abbreviation for decision support system.

ecosystem governance framework (EGF)(ToIP Governance) A governance framework for governing an entire ToIP Layer 4 digital trustecosystem.
An EGF may be either a general EGF or a specific EGF.

ecosystem of ecosystems(ToIP Governance) A digital trust ecosystem (usually of significant scale or complexity) that is governedby a general ecosystem governance framework (general EGF) for which there are multiple conforming
specific ecosystem governance frameworks (specific EGFs). An example is the Good Health Pass
digital trust ecosystem.

EGF(ToIP Governance) Abbreviation for ecosystem governance framework.

entity(W3C Verifiable Credentials Data Model 1.0) A thing with distinct and independent existence, such as aperson, organization, or device that performs one or more roles in the ecosystem.
(ESSIF Lab Glossary) Someone or something that is known to exist.

The Good Health Pass Interoperability Blueprint137

EU Digital COVID Certificate(European Union) A particular type of health credential issued by an EU member state to facilitate travelof EU citizens within the EU according to regulations specified by the European Union. Even thoughan EU Digital COVID Certificate is designed to enable travel across borders within the EU, it is not a passas defined by the Good Health Pass glossary because it does not apply the data minimization or anticorrelation required to be Good Health Pass-compliant.

event record(ToIP Glossary) A record of the data inputs associated with a particular event.

form(ToIP Glossary) A domain-agnostic data structure used to collect data. A form may be either a paper form
or a digital form. A form can contain attributes from one or more schema.

foundational interoperability(HIMSS) The first of the four levels of interoperability defined by HIMSS. This level establishes the interconnectivity requirements needed for one system or application to securely communicate data to andreceive data from another. See also structural interoperability (level 2), semantic interoperability (level3), and organizational interoperability (level 4).

general ecosystem governance framework (general EGF)
(ToIP Glossary) An ecosystem governance framework (EGF) that is intended to only be directly binding
on a governing authority defining a specific ecosystem governance framework. An example of ageneral EGF is the Good Health Pass Ecosystem Governance Framework.

general EGF(ToIP Governance) Abbreviation for general ecosystem governance framework.

GHP(GHP Glossary) Abbreviation for Good Health Pass.

GHPC(GHP Glossary) Abbreviation for Good Health Pass Collaborative.

GHP-compliant(GHP Glossary) Abbreviation for Good Health Pass-compliant.

GHP EGF(GHP Glossary) Abbreviation for Good Health Pass Ecosystem Governance Framework.

GHP Foundation(GHP Glossary) Abbreviation for Good Health Pass Foundation.

GHP Glossary(GHP Glossary) This document.

Good Health Pass (GHP)(GHP Glossary) A generic class of health passes that conform to the requirements of the Good HealthPass Ecosystem Governance Framework.

Good Health Pass Collaborative (GHPC)(GHP Glossary) A project of ID2020 to specify and advocate for the Good Health Pass.

The Good Health Pass Interoperability Blueprint

138

Good Health Pass community(GHP Glossary) The trust community of stakeholders in the Good Health Pass Ecosystem Governance
Framework.

Good Health Pass-compliant (GHP-compliant)(GHP Glossary) The condition under which a governed party has been determined to conform to the trust
assurance requirements of the Good Health Pass Ecosystem Governance Framework (GHPEGF) or a
specific EGF based on the GHPEGF.

Good Health Pass digital trust ecosystem(GHP Glossary) The digital trust ecosystem governed by the Good Health Pass Ecosystem Governance
Framework (GHP EGF) and all specific EGFs based on the GHP EGF.

Good Health Pass Ecosystem Governance Framework (GHP EGF)
(GHP Glossary) The general ecosystem governance framework that governs the Good Health Pass
digital trust ecosystem. This glossary is a controlled document of the GHP EGF.

Good Health Pass Foundation(GHP Glossary) A proposed name for the official governing authority for the Good Health Pass
Ecosystem Governance Framework.

Good Health Pass implementation(GHP Glossary) An implementation of any component of the Good Health Pass digital trust ecosystem
for which requirements are specified in the GHP EGF. This includes hardware, software, and network
services used by issuers, holders, and verifiers of GHP-compliant health credentials and healthpasses. It also includes digital wallet apps, rules engines, and decision support systems.

Good Health Pass Interoperability Blueprint(GHP Glossary) The final recommendations from the ToIP Interoperability Working Group for Good
Health Pass as compiled and approved by the Good Health Pass Collaborative.

Good Health Pass solution provider(GHP Glossary) An entity that provides and/or operates a Good Health Pass compliant implementation.

governing authority(ToIP Governance) The legal party responsible for governing a particular governance framework. The
governing authority may or may not be the administering authority. For example, a government may
be the governing authority for a governance framework administered by an NGO as the administering
authority.

governance framework(ToIP Governance) A set of business, legal, and technical definitions, policies, specifications, and contracts
by which the members of a trust community agree to be governed in order to achieve their desired
trust objectives. In governance frameworks that follow the ToIP governance metamodel, a governanceframework is divided into a primary document and a set of controlled documents. A governanceframework is itself governed by a governing authority and in some cases may be administered by aseparate administering authority. A trust framework is a specialized form of a governance framework.
See also ecosystem governance framework.

governed party(ToIP Governance) A party that plays a role in a governance framework.

The Good Health Pass Interoperability Blueprint

139

health attestation(GHP Glossary) An attestation about a subject’s health, such as the subject having had a COVID-19 test
or vaccination.

health authority(GHP Glossary) An issuer who is authoritative for at least a portion of a subject’s health records andtherefore is trusted by at least one governing authority to issue health credentials and/or healthpasses. An example is a accredited doctor or hospital.

health certificate(GHP Glossary) A certificate containing claims from one or more one or more health records. Also
known as a medical certificate. This term is often used to refer to an official document issued by agovernment agency, public health authority, or other accredited issuer. Examples include the EU Digital
COVID Certificate and the WHO Digital Documentation of COVID-19 Certificate (DDCC).

health credential(GHP Glossary) A credential containing claims from one or more one or more health records. In thecontext of the Good Health Pass, a health credential attests that a COVID-19 test event, vaccination event,or recovery verification event occurred. The claims are the data inputs associated with the health record,such as the test results or the type and dosage of vaccination given. See also identity credential.

health record(GHP Glossary) A record of a health event for a person. In the Good Health Pass context, health events
include COVID-19 test events, vaccination events, and recovery verification events.

health pass
(GHP Glossary) A pass that contains the minimal set of data from or about one or more health records
that is required for a specific verifier (or a class of verifiers, such as airlines) to make a particular trust
decision.

holder(W3C Verifiable Credentials Data Model 1.0) A role an entity might perform by possessing one or moreverifiable credentials and generating presentations from them. A holder is usually, but not always,
a subject of the verifiable credentials they are holding. Holders store their credentials in credential
repositories.

IAL(ToIP Governance) Abbreviation for identity assurance level.

identity authentication(ToIP Governance) The process of providing assurance about the identity of an entity interacting with asystem.

identity assurance level (IAL)(ToIP Governance) The term used in the NIST 800-63B standard for what the ISO/IEC 29115:2013
standard calls identity proofing LoA.

identity credential(ToIP Glossary) A credential whose claims describe attributes of an entity’s identity. Identity credentials
can be used to perform identity binding with other credentials such as health credentials.

identity(W3C Verifiable Credentials Data Model 1.0) The means for keeping track of entities across contexts.
Digital identities enable tracking and customization of entity interactions across digital contexts, typically
The Good Health Pass Interoperability Blueprint

140

using identifiers and attributes. Unintended distribution or use of identity information can compromise
privacy. Collection and use of such information should follow the principle of data minimization.

identity authentication zone
(GHP Glossary) A phase in the lifecycle of a credential or pass describing a health event (such as a
COVID-19 test or vaccination) during which the subject’s identity may need to be authenticated to somelevel of assurance. Zone 1 is at the time of vaccination or testing, zone 2 is at the time of issuance of thecredential or pass, and zone 3 is at the time of presentation.

identity authority(GHP Glossary) An issuer who is authoritative for a credential attesting to an entity’s real-world identity.
An example is a government passport agency.

identity binding(ToIP Glossary) The method by which a subject is linked (“bound”) to a credential or pass issued to that
subject. There are different methods an issuer can use to perform identity binding and that a verifier
can use to authenticate the subject against that identity binding. In the Good Health Pass digital trust
ecosystem, the processes involved in creating and authenticating an identity binding takes place acrossthree zones: zone 1, zone 2, and zone 3.

identity proofing(ToIP Glossary) The process of verifying the claimed identity of a subject by authenticating the identity
source documents and other information provided by or obtained in relation to the subject.

identity proofing LoA(ToIP Glossary) The level of assurance an issuer has in the strength of the identity proofing used for
identity binding in the issuance of a credential or pass. This term comes from the ISO/IEC 29115:2013
standard; the NIST 800-63A standard uses the term identity assurance level (IAL).

individual(ToIP Glossary) See natural person.

interoperability(Wikipedia) A characteristic of a product or system, whose interfaces are completely understood, to workwith other products or systems, at present or in the future, in either implementation or access, without any
restrictions.
(HIMSS) The ability of different information systems, devices and applications (systems) to access,exchange, integrate and cooperatively use data in a coordinated manner, within and across organizational,
regional and national boundaries, to provide timely and seamless portability of information and optimize
the health of individuals and populations globally. The four levels of interoperability defined by HIMSS
include foundational interoperability (level 1), structural interoperability (level 2), semanticinteroperability (level 3), and organizational interoperability (level 4).

issuance(ToIP Glossary) The act of an issuer issuing a credential or pass to a holder.

issuer(W3C Verifiable Credentials Data Model 1.0) A role an entity can perform by asserting claims about
one or more subjects, creating a verifiable credential from these claims, and transmitting the verifiable
credential to a holder.

The Good Health Pass Interoperability Blueprint141

jurisdiction(ESSIF Lab Glossary) The composition of a legal system (legislation, enforcement thereof, and conflict
resolution), a party that governs that legal system, a scope within which that legal system is operational,
and one or more objectives for the purpose of which the legal system is operated. For full context, see thefull ESSIF Lab Jurisdictions pattern.

legal entity(GHP Glossary) Any type of entity that has legal rights and responsibilities except a natural person.
Examples of legal entities include corporations, partnerships, sole proprietorships, associations,
governments, and non-governmental organizations (NGOs). See also party.
(ESSIF Lab Glossary) An entity that is known by, recognized to exist, and registered in a specificjurisdiction.

Legal Entity Identifier (LEI)(Wikipedia) A unique global identifier for legal entities in the form of a 20-character, alpha-numeric code
based on the ISO 17442 standard.

legal person(ESSIF Lab Glossary) An entity that is not a human being but is still endowed with legal rights associatedwith personhood in a jurisdiction (such as enterprises). See also person, legal entity, and party.

legal system(ESSIF Lab Glossary) A system in which rules are defined, and mechanisms for their enforcement andconflict resolution are (implicitly or explicitly) specified.

level of assurance (LOA)(ToIP Glossary) A measure—often on a numeric scale—of the confidence one entity has in an assertion
about another entity based on a defined set of criteria for evaluating that confidence. LoAs are often
defined in or referenced by governance frameworks and trust assurance frameworks. The Good
Health Pass Interoperability Blueprint follows the ISO/IEC 29115:2013 standard which defines four
LoA. Each LoA describes the degree of confidence in the processes leading up to and including theauthentication process itself, thus providing assurance that the entity claiming a particular identity (i.e.,
the entity) is in fact the entity to which that identity was assigned. See also authentication LoA and
identity proofing LoA.

linked data
(W3C CCG JSON-LD 1.1) A set of documents, each containing a representation of a linked data graph.

linked data graph(W3C CCG JSON-LD 1.1) A labeled directed graph, i.e., a set of nodes connected by edges, as specifiedin
the Data Model section of the JSON-LD specification [JSON-LD11CG]. A linked data graph is a generalized
representation of an RDF graph as defined in [RDF-CONCEPTS].

linked data proof(W3C CCG Linked Data Proofs 1.0) A set of attributes that represent a linked data digital proof and theparameters required to verify it.

linked data signature(W3C CCG Linked Data Proofs 1.0) A type of linked data proof that involves cryptographic signatures.

LoA(ToIP Glossary) Abbreviation for level of assurance.

The Good Health Pass Interoperability Blueprint142

mandate(ToIP Governance) The set of requirements defined in IETF RFC 2119 that use the keywords MUST, MUST
NOT, SHALL, SHALL NOT or REQUIRED.

minimization function(GHP Glossary) A sequence of steps used to compact a verifiable pass or credential and then encode
it into a URI-compliant and QR-friendly format. Each minimization function uses a combination of
methods in a pre-defined order, for example: manual and automated templating (e.g. PathCheck, JSONTX), canonicalization, serialization, normalization and binarization (e.g. CBOR, RDF), data compression(e.g. ZLIB, GZIP, 7-Zip), character encoding (e.g. Base32, percent encoding), final formatting (e.g. URI
documents, MIME types, File headers, etc).

natural person(ToIP Governance) A person that is known, for example through some form of legal registration, in ajurisdiction. See also legal person and legal entity. See the eSSIF-Labs Parties, Actors, and Actions
pattern and the eSSIF-Lab Jurisdictions pattern for more information.

non-custodial wallet(ToIP Glossary) A digital wallet in which the private keys are held directly by the holder and not by any
trusted third party acting as a custodian. In most cases a non-custodial wallet operates as a digitalwallet app on a mobile phone or other local device. Mutually exclusive with custodial wallet.

non-GHP(GHP Glossary) A qualifier used before any term in the GHP Glossary (e.g., credential, pass, issuer, verifier,rules engine, trust registry, etc.) to mean that the referent of the term is not GHP-compliant.

non-W3C verifiable credential(ToIP Glossary) A verifiable credential that does not conform to the W3C Verifiable Credentials Data
Model 1.0 standard. Mutually exclusive with W3C verifiable credentials.

nonce(Wikipedia) In cryptography, a nonce is an arbitrary number that can be used just once in a cryptographic
communication. It is often a random or pseudo-random number issued in an authentication protocol
to ensure that old communications cannot be reused in replay attacks. A nonce can also be useful for
initialization vectors and in cryptographic hash functions.

objective(ESSIF Lab Glossary) Something toward which a party directs effort (an aim, goal, or end of action). (ISO27000) result to be achieved.

offline credential(ToIP Glossary) A credential designed to work entirely offline, i.e., without an Internet connection. An
offline credential may be either a paper credential or a digital credential but it is always stored in a noncustodial wallet. In both cases the credential can be presented and verified with full functionality using
local resources, i.e., without access to the internet. An offline credential can be transmitted via a QRcode,
Bluetooth APIs, or other near-range technologies. Mutually exclusive with online credential.

online credential(ToIP Glossary) A digital credential designed to work online, i.e., that requires Internet access to achieve
full functionality. An example of an online credential is one that is stored in a custodial wallet. Mutually
exclusive with offline credential.

The Good Health Pass Interoperability Blueprint143

option(ToIP Governance) The set of requirements defined in IETF RFC 2119 that use the keywords MAY or
OPTIONAL.

organization(ESSIF Lab Glossary) A party that is associated with a group of actors that work to realize its objectives.
See the eSSIF-Labs Parties, Actors, and Actions pattern for more information. See also legal entity.
(ISO 27000) person or group of people that has its own functions with responsibilities, authorities andrelationships to achieve its objectives.

organizational interoperability(HIMSS) The fourth of the four levels of interoperability defined by HIMSS. This level Includes
governance, policy, social, legal and organizational considerations to facilitate the secure, seamless andtimely communication and use of data both within and between organizations, entities and individuals.
These components enable shared consent, trust and integrated end-user processes and workflows.
See also foundational interoperability (level 1), structural interoperability (level 2), and semanticinteroperability (level 3).

paper credential(ToIP Glossary) An offline credential printed on a physical medium (such as paper) so that when it isread by a scanner, it can be converted back into a digital credential of some type. Mutually exclusivewith digital credential. A paper credential may or may not be a verifiable credential. Even though it has“paper” on the name, any other non-electronic material can be used. A paper credential must use a QR
code or similar data transfer protocol due to the lack of electronics.

paper pass
(GHP Glossary) A pass rendered in a paper format that contains at least some data in a machine-readable
format such as a QR code or barcode. Mutually exclusive with digital pass. A paperpass may or may not
be a verifiable pass.

party(ESSIF Lab Glossary) An entity that sets its objectives, maintains its knowledge, and uses thatknowledge to pursue its objectives in an autonomous (sovereign) manner. Humans and organizations are
the typical examples. See the eSSIF-Labs Parties, Actors, and Actions pattern for more information.

passport(GHP Glossary) A passport is an international standard travel document as defined by ICAO. It is usually
issued by a country’s government to its citizens to certify the identity and nationality of the holder.
Passports may contain information such as the subject’s name, place and date of birth, photograph,signature, and other relevant identifying information. Contrast with pass.

pass(GHP Glossary) A credential to which data minimization and anti-correlation protections have been
applied and any relevant travel data has been added so it discloses only the data a verifier needs tomake a trust decision in a specific context (such as boarding an airplane). Contrast with credential,
which includes all relevant data from a record and is not required to apply data minimization or anticorrelation. A pass may be: a) issued directly from the issuer’s authoritative data records, b) issued by aproxy issuer on the basis of other attestations, certificates, or credentials presented by the holder, or c)derived directly from a verifiable credential that supports selective disclosure to produce a particularverifiable presentation with only the data required by a verifier. A pass may be either a digital pass or apaper pass. See also verifiable pass.

The Good Health Pass Interoperability Blueprint

144

person(ToIP Governance) A human being. See also natural person, legal person, legal entity, and party.

personhood(ToIP Governance) The status of being a party to which the same Hohfeldian right and duties (including
accountability) can be attributed as to a person. Thus, enterprises (that are not a person), may
nevertheless be assigned rights and duties as if they were one.

personal data
(EU General Data Protection Regulation) any information relating to an identified or identifiable natural
person.

PKI(Wikipedia) Abbreviation for Public Key Infrastructure.

presentation(W3C Verifiable Credentials Data Model 1.0) Data derived from one or more verifiable credentials,
issued by one or more issuers, that is shared with a specific verifier.

presentation definition(DIF Presentation Exchange v1.0.0) An object that articulates what proofs a verifier requires. These help
the verifier to decide how or whether to interact with a holder. Presentation definitions are composedof inputs, which describe the forms and details of the proofs they require, and optional sets of selection
rules, to allow holders flexibility in cases where many different types of proofs may satisfy an input
requirement.
(ToIP Glossary) A digital object defining what proof(s) a verifier requires from a holder in order for theverifier to make a trust decision. See the DIF Presentation Exchange specification.

presentation request(ToIP Glossary) A data structure sent from a verifier to a holder to request a particular presentation
definition. Also known as proof request.

presentation submission(DIF Presentation Exchange v1.0.0) An object embedded within target claim negotiation formats thatunify the presentation of proofs to a verifier in accordance with the requirements the verifier specified in apresentation definition.
(ToIP Glossary) A digital object providing the proof(s) a holder has selected to submit to a verifier in
response to a presentation request. See the DIF Presentation Exchange specification.

primary document(ToIP Glossary) The starting point document of a governance framework that follows the modular
architecture of the ToIP governance metamodel. In this metamodel, the primary document is required toinclude a list of all other controlled documents.

privacy and consent notice(GHP Glossary) A consent receipt or a proof of acknowledgement that a person has read, understood aprivacy notice and/ or consented to the processing of their personal data.

protected health information (PHI)(Wikipedia) Any information about health status, provision of health care, or payment for health carethat is created or collected by a healthcare provider and can be linked to a specific individual.

The Good Health Pass Interoperability Blueprint145

proof(ToIP Glossary) Cryptographic verification of a claim or a credential, typically provided by the issuer,
but may also be generated by the holder based on the original proof(s) provided by the issuer. A digital
signature is a simple form of proof. A cryptographic hash is also a form of proof. Zero knowledge proofs
enable selective disclosure of the information in a credential.

proof request(ToIP Glossary) See presentation request.

proxy issuer(GHP Glossary) An issuer who is not authoritative for the source data for a certificate or credential,
but who serves as a verifier of one or more certificates or credentials as part of the process of issuing averifiable pass. A proxy issuer may function as a rules engine and/or decision support system. A proxyissuer may perform other processing including applying business logic, performing data validation andnormalization, and applying data minimization and anti-correlation.

pseudonymous data
(EU General Data Protection Regulation) Personal data that has been processed in such a manner thatthe personal data can no longer be attributed to a specific data subject without the use of additional
information, provided that such additional information is kept separately and is subject to technical andorganisational measures to ensure that the personal data are not attributed to an identified or identifiable
natural person.

public key certificate(Wikipedia) An electronic document used to prove control of a public key.

QR code(Wikipedia) A type of machine-readable two-dimensional barcode that can be read by an opticalscanner to convey information defined in the ISO/IEC 18004:2015 specification (full name: “Information
technology — Automatic identification and data capture techniques — QR Code 2005 bar code symbology
specification).

recommendation(ToIP Governance) The set of requirements defined in IETF RFC 2119 that use the keywords SHOULD,SHOULD NOT, or RECOMMENDED.

record(ToIP Glossary) A collection of domain-specific data inputs, possibly of different data types, typically in a
fixed number and sequence within a database.

relying party(ToIP Glossary) A party who chooses to rely on a credential once it has been verified. The W3C Verifiable
Credentials community uses the term verifier for this role. Other specifications, particularly thosedefining federated identity management systems, use the term “relying party”.
(ToIP Governance) A party who relies on the assertions or attestations of a governed party overconformance with all or part of a governance framework, often as measured against a trust assurance
framework.

repository(W3C Verifiable Credentials Data Model 1.0) A program, such as a storage vault or personal verifiable
credential wallet, that stores and protects access to holders’ verifiable credentials.

The Good Health Pass Interoperability Blueprint146

requirement(ToIP Governance) Any statement in a governance framework or one of its controlled documents that uses
one of the keywords defined in IETF RFC 2119. Requirements are either mandates, recommendations, or
options.

revocation(ToIP Glossary) The act of an issuer asserting that a credential it issued is no longer valid.

revocation registry(ToIP Glossary) A network service available from one or more service endpoints specified in agovernance framework that can be queried by a verifier (or other relevant party) to check whether acredential has been revoked. For verification of offline credentials, the entries in a revocation registry
may need to be periodically downloaded by the verifier.

risk(ESSIF Lab Glossary) the deviation of the expected realization (e.g. results) of a party’s objective.
(ISO 27000) effect of uncertainty on objectives. An effect is a deviation from the expected - positive or
negative. Uncertainty is the state, even partial, of deficiency of information related to, understanding or
knowledge of, an event, its consequence, or likelihood.

risk analysis(ISO 27000) process to comprehend the nature of risk and to determine the level of risk (risk level).

risk assessment(ToIP Glossary) A process of evaluating threats to the purpose, scope and objectives of a governanceframework and categorizing them so that risk treatment options (mitigation, avoidance, acceptance ortransference) can be considered and applied. A risk assessment can evaluate threats of any type: external
attackers, insider threats, information technology limitations or failures, market risks, legal risks, and soon.
(ISO 27000) The overall process of risk identification, risk analysis and risk evaluation.

risk evaluation(ISO 27000) The process of comparing the results of risk analysis with risk criteria to determine
whether the risk and/or its magnitude (risk level) is acceptable or tolerable.

risk identification(ISO 27000) The process of finding, recognizing and describing risks.

risk owner(ISO 27000) The person or entity with the accountability and authority to manage a risk.

risk level (or: level of risk)(ISO 27000) The magnitude of a risk, expressed in terms of the combination of consequences and theirlikelihood.

risk treatment(ISO 27000) The process to modify a risk. Risk treatment can involve:- avoiding the risk by deciding not to start or continue with the activity that gives rise to therisk;- taking or increasing risk in order to pursue an opportunity;- removing the source/cause of the risk;
The Good Health Pass Interoperability Blueprint147

- changing the likelihood (chance) of the risk materializing;- changing the outcome of a security event, affecting objectives;- sharing the risk with another party or parties (including contracts and risk financing);- retaining the risk by informed choice.

risk treatment plan (RTP)(ToIP Governance) A component of a trust assurance framework that states how identified risks shall betreated, e.g. mitigated, avoided, accepted or transferred.

role(ToIP Glossary) A context-dependent specialization class of actors and/or parties that have specificproperties and/or perform specific functions in such contexts. A role is identifiable by the context in which
it occurs and its role name. For example, in a technical context, a role may refer to a set of permissions
and a set of users (NIST RBAC standard), in an enterprise context is may refer to an organizational
function that employees can have, and that come with benefits, salary and responsibilities, and in agovernance context it may refer to a set of rights, responsibilities, and requirements that apply to aparticular governed party in the scope of a governance framework.

role name(ToIP Glossary) The name by which a role can be identified in a particular context. Using it without
properly referencing the context may cause misunderstandings, as role names refer to different roles indifferent contexts. For example, the role name ‘issuer’ would typically refer to a party in e.g. a governancecontext, while it would typically refer to an actor in e.g. a technical context.

root certificate(ToIP Glossary) The first certificate in a certificate chain that represents the root of trust for that chain.

root DID(ToIP Glossary) The first DID in a DID chain that represents the root of trust for that chain.

root of trust(ToIP Glossary) The starting point for a certificate chain or a DID chain.
(GHP Glossary) A trust registry designated by a governing authority in a specific ecosystemgovernance framework by specifying the root certificate or root DID and the trust registry service
endpoint.

RTP(ToIP Governance) Abbreviation for risk treatment plan.

rule(ToIP Glossary) A deterministic machine-readable conditional statement that evaluates to an outcome. See
business rule.

rules engine(Wikipedia) A software system that executes one or more business rules in a runtime production
environment.

schema(ToIP Glossary) A machine-readable definition of the semantics of a domain-specific data structure.

The Good Health Pass Interoperability Blueprint148

selective disclosure(W3C Verifiable Credentials Data Model 1.0) The ability of a holder to make fine-grained decisions about
what information to share.

self-attestation(ToIP Governance) An attestation made by a subject about itself. An example is a self-attestation by aperson about a lack of COVID-19 symptoms within a specified period, or a self-attestation by a legal
entity about conformance to a governance framework.

semantic interoperability(HIMSS) The third of the four levels of interoperability defined by HIMSS. This level provides for common
underlying models and codification of the data including the use of data elements with standardized
definitions from publicly available value sets and coding vocabularies, providing sharedunderstanding andmeaning to the user. See also foundational interoperability (level 1), structural interoperability (level 2),
and organizational interoperability (level 4).

service(W3C Decentralized Identifiers 1.0) Means of communicating or interacting with the DID subject orassociated entities via one or more service endpoints. Examples include discovery services, agent
services, social networking services, file storage services, and verifiable credential repository services.

service endpoint(W3C Decentralized Identifiers 1.0) A network address, such as an HTTP URL, at which services operate
on behalf of a DID subject.

Smart Health Card
(Microsoft) A specification from Microsoft Health for producing verifiable credentials from Fast
Healthcare Interoperability Resources (FHIR) health records. See https://smarthealth.cards/

specific ecosystem governance framework (specific EGF)
(ToIP Governance) An ecosystem governance framework that complies with the requirements of ageneral ecosystem governance framework (general EGF). A specific EGF is designed to govern a
specific trust community within the larger digital trust ecosystem established by the general EGF withwhich it complies.

specific EGF(ToIP Governance) Abbreviation for specific ecosystem governance framework.

structural interoperability(HIMSS) The second of the four levels of interoperability defined by HIMSS. This level defines theformat, syntax and organization of data exchange including at the data field level for interpretation. See
also foundational interoperability (level 1), semantic interoperability (level 3), and organizational
interoperability (level 4).

subject(W3C Verifiable Credentials Data Model 1.0) A thing about which claims are made.
(ToIP Glossary) The entity identified by a DID and/or described by a verifiable credential. See also DID
subject.

TAF(ToIP Governance) Abbreviation for trust assurance framework.

The Good Health Pass Interoperability Blueprint

149

TIP
(ToIP Glossary) Abbreviation for ToIP Interoperability Profile.

ToIP(ToIP Glossary) Abbreviation for Trust over IP.

ToIP Foundation(ToIP Glossary) A non-profit project organized under the Joint Development Foundation model hosted by
the Linux Foundation for defining interoperable decentralized digital trust infrastructure based on the ToIP
stack.

ToIP governance metamodel(ToIP Glossary) The model for structuring a governance framework developed by the ToIP Foundation.
See https://wiki.trustoverip.org/display/HOME/ToIP+Governance+Metamodel. GHP-compliant
governanceframeworks MUST follow the ToIP governance metamodel.

ToIP Interoperability Profile (TIP)(ToIP Glossary) A collection of ToIP Standard Specifications, other open standard specifications, andassociated recommendations and best practices for how a particular set of trust communities agrees tointeroperate technically across the four layers of the ToIP stack.

ToIP trust model(ToIP Glossary) A model for achieving transitive trust across trust communities using the ToIP stack
defined by the ToIP Foundation. See the ToIP white paper.

ToIP stack(ToIP Glossary) The four-layer dual stack of technology and governance defined by the ToIP Foundationthat enables transitive trust across trust communities. See the ToIP white paper.

ToIP Standard Specification (TSS)(ToIP Glossary) A specification for decentralized digital trust infrastructure approved and published by the
ToIP Foundation.

transitive trust(ToIP Glossary) The ability of one trust community member to make a trust decision about another trust
community member in that same trust community or a different one.

travel authority(GHP Glossary) An issuer who is not authoritative for a subject’s health records but is trusted by at least
one governing authority to access those health records with the consent of the subject for the purposeof issuing health credentials and/or health passes for enabling freedom of travel. An examplewould be agovernment travel office or an airline industry association.

travel context(GHP Glossary) A specific juncture in a traveler’s journey where the traveler might be required to present a
relevant credential or pass. Examples include border crossings, ticket bookings, airline boardings, healthfacility visits, and so on.

travel data
(GHP Glossary) Data describing a traveller’s journey, such as itineraries, declarations, restrictions, and soon.

The Good Health Pass Interoperability Blueprint150

travel document system(GHP Glossary) An information processing system designed to automate the workflow and production of
travel data into either digital or paper travel documents such as boarding passes, itineraries, passenger
locator forms, and so on.

travel pass
(GHP Glossary) A specialized form of a pass intended to represent a determination of admissibility of a
traveler to a jurisdiction.

trust community(ToIP Glossary) A set of parties who agree to cooperate and interoperate to achieve a set of trust
objectives online. In the ToIP trust model, such agreement is formalized in a governance framework.
Actors and parties may participate in any number of independent trust communities and may use theToIP trust model to achieve transitive trust across those communities.

trust community member(ToIP Glossary) A governed party within a trust community.

trust decision(ToIP Glossary) A decision by a party about whether or not it will engage in an interaction or transaction
with another party, which includes a determination by the first party whether the risk it runs is acceptable(given its risk appetite).

trust assurance framework (TAF)(ToIP Governance) A set of specialized roles, policies, and processes defined by a governing authority—
usually as a subcomponent of a governance framework—to specify how governed parties can be held
accountable for compliance to a stated level of assurance.

trust framework(ToIP Governance) A specialized form of a governance framework specifying how a set of governed
parties agree to cooperate and interact to achieve their trust objectives at specified levels of
assurance.

trust mark
(ToIP Governance) An official seal, authentication feature, certification, license, or logo that is provided
by a governing authority (or its delegate) to a governed party as authorized under its trust assurance
framework to signify that the party is in compliance with the governance framework.

trust objective(ToIP Governance) An objective of one or more parties to make successful trust decisions. In the ToIP
trust model, the trust objectives shared by the members of a trust community are formalized in agovernance framework. Note that individual members of a trust community may have different trust
objectives than those of the community as a whole, however there is enough overlap to provide sufficientincentive for all members to join the trust community.

Trust over IP(ToIP Glossary) An architecture for decentralized digital trust infrastructure developed and specified by the
ToIP Foundation. The core of the architecture is the ToIP stack. See the ToIP white paper.

trust registry(ToIP Glossary) A network service available from one or more service endpoints specified in agovernance framework that can be queried to determine if a party is authorized to perform a specific

The Good Health Pass Interoperability Blueprint151role or action. A common example is a verifier querying a trust registry to determine if the issuer of averifiable credential is an authoritative issuer for a specific verifiable credential type. Another exampleis
a holder querying a trust registry to determine if a verifier is authorized to make a specific presentation
request. If a trust registry serves multiple governance frameworks, the trust registry data may also
include the governance framework(s) under which issuers and verifiers are authorized. A trust registry canhost any data or metadata that assists the querying party in making a trust decision. To support offline
credentials, the records in a trust registry may need to be periodically downloaded by the verifier.

trusted third party (TTP)(ToIP Glossary) A third party who is trusted by two parties to facilitate interactions or transactions
between the two parties.

TSS(ToIP Glossary) Abbreviation for ToIP Standard Specification.

TTP(Wikipedia) Abbreviation for trusted third party.

URI(W3C Decentralized Identifiers 1.0) Abbreviation for Uniform Resource Identifier.

Uniform Resource Identifier(W3C Decentralized Identifiers 1.0) The standard identifier format for all resources on the World Wide Web
as defined by IETF RFC 3986. A DID is a type of URI scheme.

VC(W3C Decentralized Identifiers 1.0) Abbreviation for verifiable credential.

vaccination certificate(GHP Glossary) A health certificate describing a vaccination event.

vaccine passport(GHP Glossary) A misnomer for a health credential or health pass. IT IS VERY STRONGLY
RECOMMENDED TO NEVER USE THIS TERM.

validation(W3C Verifiable Credentials Data Model 1.0) The assurance that a verifiable credential or a verifiable
presentation meets the needs of a verifier and other dependent stakeholders. This specification isconstrained to verifying verifiable credentials and verifiable presentations regardless of their usage.
Validating verifiable credentials or verifiable presentations is outside the scope of this specification.

verification(W3C Verifiable Credentials Data Model 1.0) The evaluation of whether a verifiable credential orverifiable presentation is an authentic and timely statement of the issuer or presenter, respectively. This
includes checking that: the credential (or presentation) conforms to the specification; the proof method issatisfied; and, if present, the status check succeeds.

verification method(W3C Decentralized Identifiers 1.0) A set of parameters that can be used together with a process toindependently verify a proof. For example, a cryptographic public key can be used as a verificationmethodwith respect to a digital signature; in such usage, it verifies that the signer possessed the associatedcryptographic private key.

The Good Health Pass Interoperability Blueprint152

verifiable credential (VC)
(W3C Verifiable Credentials Data Model 1.0) A tamper-evident credential that has authorship that can be
cryptographically verified. Verifiable credentials can be used to build verifiable presentations, which canalso be cryptographically verified. The claims in a credential can be about different subjects.
(GHP Glossary) A verifiable credential may be either a digital credential or a paper credential.

verifiable credential type
(ToIP Glossary) A URI used as the value of a verifiable credential type property to identify its specific
type as defined in section 4.3 of the W3C Verifiable Credentials Data Model 1.0 specification.

verifiable data registry(W3C Decentralized Identifiers 1.0) A system that facilitates the creation, verification, updating, and/or
deactivation of decentralized identifiers and DID documents. A verifiable data registry might also be
used for other cryptographically-verifiable data structures such as verifiable credentials.

verifiable presentation (VP)
(W3C Verifiable Credentials Data Model 1.0) A tamper-evident presentation encoded in such a waythat authorship of the data can be trusted after a process of cryptographic verification. Certain typesof verifiable presentations might contain data that is synthesized from, but do not contain, the original
verifiable credentials (for example, zero-knowledge proofs).
(GHP Glossary) A presentation that conforms to the requirements of a verifiable presentation in the
W3C Verifiable Credentials Data Model 1.0 standard.

verifiable QR code
(ToIP Glossary) A QR code that contains a verifiable credential or a verifiable pass.

verifiable pass
(GHP Glossary) A pass that can be cryptographically verified in the same manner as a verifiable
credential. A verifiable pass may be either a digital pass or a paper pass.

verifier(W3C Verifiable Credentials Data Model 1.0) A role an entity performs by receiving one or moreverifiable credentials, optionally inside a verifiable presentation for processing. Other specifications
might refer to this concept as a relying party.

VP(W3C Verifiable Credentials Data Model 1.0) Abbreviation for verifiable presentation.

W3C(ToIP Glossary) Abbreviation for the World Wide Web Consortium.

W3C Decentralized Identifiers (DIDs) 1.0(ToIP Glossary) The W3C standard for DIDs published at https://www.w3.org/TR/did-core/.

W3C verifiable credential(ToIP Glossary) A verifiable credential that conforms to the W3C Verifiable Credentials Data Model
1.0 standard. Mutually exclusive with non-W3C verifiable credentials, such as ePassports, which are
cryptographically verifiable but do not conform to the W3C Verifiable Credentials Data Model 1.0 standard.

W3C Verifiable Credentials Data Model 1.0(ToIP Glossary) The W3C standard for verifiable credentials published athttps://www.w3.org/TR/vcdata-model/.

The Good Health Pass Interoperability Blueprint

153

WHO
(ToIP Glossary) Abbreviation for the World Health Organization.

WHO Digital Documentation of COVID-19 Certificate(World Health Organization) See Digital Documentation of COVID-19 Certificate.

X.509 certificate(ToIP Glossary) A public key certificate issued following the X.509 standard.

X.509 certificate chain(ToIP Glossary) A set of X.509 certificates issued in a hierarchical model where each certificate (except
the root) is signed by the parent certificate it was derived from. Certificate chains can be verified for
cryptographic trust by “walking the chain” back to the root of trust. See also trust registry.

zero-knowledge proof (ZKP)(ToIP Glossary) A proof that uses a particular branch of cryptography to support selective disclosure of
information. A zero knowledge proof provides cryptographic verification about some or all of the data in aset of credentials without revealing the actual data or any other information about the holder. ZKP-based
credentials can be used with different presentation requests to dynamically produce verifiable passes.

ZKP(ToIP Glossary) Abbreviation for zero-knowledge proof.

zone 0(GHP Glossary) The “zone” prior to any other identity authentication zone during which the person
planning to travel may need access to a rules engine or decision support system in order to determine
what health records will be needed to obtain the necessary health pass(es) for a particular journey.

zone 1(GHP Glossary) The first identity authentication zone in which the health event resulting in a healthrecord takes place, e.g., a COVID-19 test, vaccination, or proof of recovery test. If the patient is alreadyenrolled in a healthcare system, the patient will typically need to be authenticated prior to the health
event. If the patient is not enrolled, the healthcare system will typically need to collect the identity
information necessary to do identity binding so the patient can be authenticated in zone 2. However thismay or may not be possible for some health events (such as vaccinations given during a pandemic).

zone 2(GHP Glossary) The second identity authentication zone in which a credential or pass is issued to theholder by an issuer. If identity binding data was collected in zone 1, the holder must be authenticatedby the issuer to whatever level of assurance is supported by the available identity binding data. If identity
binding was not performed in zone 1, or if it was not performed to an adequate level of assurance, in zone
2 it may be possible to supplement the patient identity data and increase the level of assurance beyond
what was collected in zone 1. However this depends on the capabilities of the issuer and attestations of
the patient or other witnesses to the health event.

zone 3(GHP Glossary) The third identity authentication zone in which a credential or pass is presented by
the holder to a verifier. In this zone the verifier MUST use the identity binding data from zone 2 toauthenticate the holder to the level of assurance required by the verifier (but this level cannot exceed
the level of assurance achieved in zone 2).

The Good Health Pass Interoperability Blueprint154

Acknowledgements
Rebecca Distler and Kaliya Young
Co-Chairs, Interoperability Working Group for Good Health Pass
Thank you to the following individuals and organizations for their contributions to the Good Health Pass
Interoperability Blueprint and participation in the Interoperability Working Group for Good Health Pass at
Trust over IP:
Abdul Sattar (USA), Alessandro Minucci (Portugal), Alex Fryer (UK), Andy Smith (UK), Ann Cavoukian(Canada), Areiel Wolanow (UK), Aya Kubota (Japan), Bart Suichies (Switzerland), Bejoy A K (India), Brent
Zundel (USA), Brian Plew (USA), Dr. Brian Martin (USA), Bryn Robinson-Morgan (UK), Burak Serdar(USA), Charles Walton (USA), Chester Drum MD PhD (Singapore), Chris Raczkowski (Canada), Christian
Buchanan (USA), Christopher Justice (UK), Chuck Curran (USA), Colin Wallis (UK), Dakota Gruener(USA), Dan Johnson (UK), Daniel Bachenheimer (USA), Darrell O’Donnell (Canada), Daryl Thomas(Canada), David Holt (Thailand), David Janes (USA), Dr. Elizabeth Evenden-Kenyon (France), Dr. Gordon
Jones (USA), Drummond Reed (USA), Elli Androulaki (Switzerland), Elli Papageorgiou (Belgium), Eric
Doherty (USA), Erica Frenkel (USA), Ethan Veneklasen (USA), Harm Jan Arendshorst (Netherlands),
Hisanori Sato (Japan), Jacques Bikoundou (USA), James Swinton-Bland (UK), Jammal Dorsey (USA), Jan
Lindquist (Sweden), Jason M. Hare (USA), Jim St.Clair (USA), Joanne Cooper (Australia), John Walker(USA), Juan Carlos Gonzalez (USA), Judith Fleenor (USA), Julian Ranger (UK), Justin Dossey (USA),
Kaliya Young (USA), Katy Reid (UK), Ken Adler (USA), Ken Mayer (USA), Lucy Yang (Canada), Lukas Svec
(USA), Mahesh Balan (USA), Manik Biswas (UK), Marcos Allende Lopez (USA), Marie Wallace (Ireland),Michael Becker (USA), Michael Boyd (USA), Michael O’Connell (UK), Mustafa Özçakır (Turkey), Noam H
Arzt (USA), Nuttawut Kongsuwan (Thailand), Paco Garcia (UK), Pagona Tsormpatzoudi (Belgium), Parul
Sumiran Agarwal (USA), Paul Knowles (Switzerland), Paul Murdock (Switzerland), Peter Davis (USA),Peter Watkins (Canada), Rajesh B Pillai (USA), Riley Hughes (USA), Rob Broere (USA), Rob Haslam (UK),
Robin Ingle (Canada), Sandeep Jain (USA), Sankarshan Mukhopadhyay (India), Sara Facchinetti (Italy),
Savita Farooqui (USA), Scott S Perry (USA), Shermineh Salehi Esmati (Canada), Sidharth Mishra, StaceyAnn Pearson (Singapore), Steve Armitage (UK), Steve Magennis (USA), Steven Milstein (Canada), Surya
Sayed-Ganguly (USA), Tim Bos (Australia), Todd Gehrke (USA), Tony Little ND (USA), Tony Rose (USA),
Travis James (USA), Trev Harmon (USA), Tricia Loveland (USA), Viky Manaila (Italy), Viola Wang (UK), Vitor
Pamplona (USA), Wang Xiang (Singapore), Wenjing Chu (USA), Xavier Vila (Spain), Yochai Legum (UK)
7 Skies Inc., Accenture, Affinidi, Airside, American Express, Australia Data Exchange, Bindle Systems, Blink
Science Inc., BLOK BioScience, Blok Solutions, Cloud Privacy Labs, Collab.Ventures, Continuum Loop
Inc., COVID-19 Credentials Initiative, Critical Insights Consultants Ltd, Dhiway Networks Pvt Ltd, Digi.
me, Evernym, Finema Company Limited, Global Privacy and Security By Design Centre Inc, GovernID,
Heathrow, HLN Consulting LLC, Human Colossus Foundation, IBM, ICTS Europe Systems, ID2020, ID
Lynx Ltd, Identity Praxis Inc, iLabs Technologies b.v., InfoCert, Intesi Group SpA, IProov, Kantara Initiative,
LACChain, Linaltec, Linux Foundation Public Health, Lumedic, Mastercard, NonProfit Organizations
Knowledge Initiative, PathCheck Foundation, PolyWug, Pravici LLC, Prescryptive Health, Proof
Market Incorporated, Proxy Inc, Roche Diagnostics, Safe Health, Salesforce, Scott S. Perry CPA PLLC,
SemanticClarity CCI, ShareRing Limited, Singapore Airlines, SITA, SymSoft Solutions, TECH5, Tested.me,
The Commons Project, The MITRE Corporation, Thermo Fisher Scientific, Thoughtworks, TODAQ, Travel
Navigator, Tribe Health Solutions, Trinsic, Trust Over IP Foundation, Uqudo, Validated ID, Vision-Box, Yoti,
Zebra Technologies

The Good Health Pass Interoperability Blueprint

155

Appendix A: Example User Flows for Obtaining a				Health Pass
COVID-19 Testing
Example 1: General Testing
1. Individual goes to lab
2. Individual presents an identity document (e.g., government issued ID)
3. Healthcare provider authenticates identity claim
4. Healthcare provider conducts test/vaccination
5. Individuals receives SMS or email with QR code embedded in PDF or printed test/vaccination report
Example 2: Public Health Testing
1. Individual goes to lab
2. Individual presents identity document (e.g., national health number)
3. Healthcare provider authenticates identity claim
4. Test results pushed to national or regional central repository
5. Individual receives SMS or email (can be stored on paper or in digital wallet/app)
Example 3: Travel-Specific Testing
1. Individual downloads app
2. Individual registers appropriate information (e.g., flight details, if not connected via API from airline
booking system)
3. Individual gets specific immigration and test requirements for trip (via API from airline booking
system)4. Individual linked to booking platform for test centre/lab to schedule test
5. Individual goes to test centre
6. Healthcare provider uses verifier app and verifies identity document (in person, not remote)7. Healthcare provider takes sample, performs test and pushes results to individual app
8. Individual can share results and identity information with carrier prior to arrival at the airport tofacilitate at-airport clearance to fly
9. Individual retains their results on app and has ability to share results with border agency(ies) upon
arrival

COVID-19 Vaccination
A person who is fully vaccinated decides to travel internationally and determines that a COVID-19 healthpass is required. They should be able to request the issuance of a GHP after authenticating themselves tothe issuer at the required authentication LoA against a pre-enrolled identity (or identity document) at therequired identity proofing LoA.
The below examples focus on steps involving software, which will work in parallel with a standalone ordigitally-linked paper credential.
Digital, Semi-Automated:

The Good Health Pass Interoperability Blueprint156

1. Individual receives appointment and any prerequisite instructions (e.g., for setting up a credential
app/health pass)
2. Individual initializes a digital credential app, provides consent and personal information
3. Individual identifies themselves at health facility
4. Health facility follows procedure to administer vaccine and collect data (including vaccine data,
individual’s personal data, dosage information, hospital records)
5. Relevant data stored in the health facilities system, and/or synchronised to a government/state
central immunisation database
6. Credential may be issued containing record of 1st vaccination (following individual’s consent) if 1stdose
7. Credential may be issued to certify individuals are vaccinated following 2nd dose (or data added tocredential if one already exists) following consent from the individual
Digital, Fully-Automated:
1. Individual follows health facility process for vaccination including identification and consent for
digital credential issuance handled by authorised entity back-end system (e.g. country/state
immunisation database)
2. Individual installs and sets up credential app/health pass (can be at a previous stage)
3. Receives notification to accept vaccine credential
4. Individual provides consent to data process/transfer
Digital, Manual (e.g., low-tech health facilities):
1. Individual receives appointment and any prerequisite instructions (e.g., for setting up a credential
app/health pass)
2. Individual initialises credential app, provides consent, personal information, and identification
document/data
3. Individual identifies themselves at health facility
4. Health facility verifies identity, follows procedure to administer vaccine and collects data into issuer
version/area of credential app (including vaccine data, dosage information, signature of issuer
entity or medical personal)
5. Credential may be issued containing record of 1st vaccination (following individual’s consent) if 1stdose
6. Credential may be issued to certify individual is vaccinated following 2nd dose (or data added tocredential if one already exists) following consent from individual

The Good Health Pass Interoperability Blueprint

157

Appendix B: COVID-19 Credentials Initiative (CCI)				
Schema Task Force Data Specification				Repositories
CCI Schema Reference Documents:
https://drive.google.com/drive/u/1/folders/1h4vF79KzUY6KipBt3A6kMEboiqcSYtv7
Global Reference Documents:
https://drive.google.com/drive/u/1/folders/1y-nr-YlacLvv7P54N6EUYVrBNt7YA51T
Jurisdiction Specific Reference Documents:
https://drive.google.com/drive/u/1/folders/1Gmapb1ktvm-v3NDH65AZEUJ-__-ouvcg

The Good Health Pass Interoperability Blueprint

158

Appendix C: OCA Background
OCA presents a schema as a multi-dimensional object consisting of a stable capture base andinteroperable overlays. Overlays are task-oriented linked data objects that provide additional coloration to
the capture base. This degree of object separation enables issuers to make custom edits to the overlays
rather than to the capture base itself. In other words, multiple parties can interact with and contribute to
the schema structure without having to change the capture base definition. With capture base definitions
remaining stable and in their purest form, a common immutable base object is maintained throughout thecapture process, which enables data standardization.

Figure 23: Overlay Stack

Explainer on OCA Objects:
Capture BaseA capture base is a stable base object that defines a single set of data in its purest form thus providing astandard base from which to decentralize data.
Attribute names and types are defined in the capture base. The construct also contains a blinding block
which allows the issuer to flag any attributes that could potentially unblind the identity of a governing
entity. With these attributes flagged at the base layer, all corresponding data can be treated as sensitive
throughout the data lifecycle and encrypted or removed at any stage thus reducing the risk of identifying
governing entities in blinded datasets.

Meta Overlay
A meta overlay is a core linked object that can be used to add contextual meta-information about theschema, including schema name, description and broad classification schemes.

Character Encoding Overlay
A character encoding overlay is a core linked object that can be used to define the character set
encoding (e.g. UTF-8, ISO-8859-1, Windows-1251, Base58Check, etc.). This overlay type is useful when
implementing solutions that facilitate data inputs across multiple languages.

The Good Health Pass Interoperability Blueprint

159

Format Overlay
A format overlay is a core linked object that can be used to add formats, field lengths, or dictionary coding
schemes to schema attributes.

Entry Overlay
An entry overlay is a core linked object that can be used to add predefined field values in a specified
language to schema attributes. To minimize the risk of capturing unforeseen PII, the implementationof free form text fields is best avoided. This overlay type enables structured data to be entered thereby
negating the risk of capturing and subsequently storing dangerous data.

Label Overlay
A label overlay is a core linked object that can be used to add labels in a specified language to schema
attributes and categories. This overlay type enables labels to be displayed in a specific language at thepresentation layer for better comprehensibility to the end user.

Information Overlay
An information overlay is a core linked object that can be used to add instructional, informational or legal
prose to assist the data entry process.
https://wiki.colossi.network/en/Technologies/OCA/Developer/Adopt

The Good Health Pass Interoperability Blueprint160

Appendix D: FHIR-OCA Data Pipeline
HL7 FHIR formatted data is being specified as a preferred exchange format for EHR data being processed
into vaccination, test or recovery certificates for the EU DGC, WHO DDCC, VCI and other initiatives.
The respective FHIR communities are creating FHIR Implementation Guides that provide technicaldirection on how to create and structure the relevant FHIR resources to be processed. This support
from the FHIR communities helps to ensure that FHIR formatted record sets will be widely available forprocessing. HL7 has several other formats for health data exchange; these formats 2.x, 3.x, and CDA havelibraries and mappings to support the conversion of data formatted from their respective formats into a
FHIR format. The conversion of data in pre-FHIR formats or conversion of non-FHIR formatted data into a
processable FHIR format for the FHIR-OCA tool can be implemented as a set of pre-processing steps prior
to pipeline processing.
Reference links for conversion of data to a FHIR format include HL7 Version 2 to FHIR, Clinical Document
Architecture (CDA), and Importing CSV data into a FHIR server.
Being that FHIR EHR data records represent clinical information from the clinical application source, there
are compliance, security and audit features available via FHIR that facilitate the accurate capture of state
for the health event being described. This in turn provides for a transparent usage of the data keeping
it aligned with the original reason for its extraction and capture. The FHIR-OCA approach to processing
assumes that these mechanisms have been applied by the clinical application.

Figure 24: Semantic Data Pipeline
In the FHIR JSON-LD (JavaScript Object Notation for Linked Data) transform, the data elements are also
structured into an OCA capture base. Next, the capture base elements have application context extracted
and transformed into a set of overlay capture objects, the set of overlay objects are pre-defined to alignwith the purpose of use of the data set.
Finally, based on the purpose of use, jurisdictional and vocabulary mappings are applied and the target
specific OCA artifacts are created. This set of OCA artifacts are then available for further encryption andpersistence processing. https://github.com/SemanticClarity/oca-fhir-cli

The Good Health Pass Interoperability Blueprint

161

Appendix E: About the Good Health Pass				
Collaborative
Launched by ID2020, the Good Health Pass Collaborative is a multi-sector global initiative to establish
principles and standards for digital health passes for international travel.
The Good Health Pass Collaborative is unique in that it is neither developing its own nor promoting any
specific technology solution or product. Rather, the Collaborative has brought together more than 120
companies and organizations from across the travel, health, and technology sectors – including all of the
major solution providers – in an attempt to dramatically streamline a standards-setting process which,under normal circumstances, might take years or even decades to complete.
Learn more at goodhealthpass.org.

The Good Health Pass Interoperability Blueprint

162