Good Health Pass compliant implementations must implement standard methods for verifying the authenticity of the holder at specified levels of assurance.
As part of determining the blueprint for overall interoperability for Good Health Pass solutions, reach consensus on an interoperable solution to identity proofing and binding for a Good Health Pass that will meet the requirements of the coalition stakeholders.
From the very start of the Good Health Pass Collaborative, there has a particular focus on one of the most vexing digital identity challenges: identity binding.
In the context of health credentials, this is the problem of how a credential describing a specific health event (such as a COVID-19 test or vaccination) can be linked – as strongly as possible – to the identity of the patient who received that care. Ideally, from a security standpoint, this binding is so strong that only that patient (or their authorized delegate) can subsequently prove the credential belongs to her/him.
Identity Binding interoperability challenge is the one we described earlier in the paper about how a Good Health Pass compliant credential can be “bound” to the individual it describes (i.e., to the person who has received a COVID-19 test or vaccination) – and how, then, can that person subsequently prove that they are, indeed, the individual bound to that credential (authentication). The three zones involved with this challenge are repeated here for convenience:
Once you separate the problem space into these three zones, certain conclusions emerge:
- Zone 1: The Good Health Pass interoperability blueprint can make no assumptions at all about what identity binding data is collected at the point of care (if any). This is entirely up to the healthcare provider or other administrator of the test or vaccination.
- Zone 2: The strength of the identity binding that can be achieved at credential issuance may depend completely on what identity binding data was (or was not) collected in Zone 1. However, in some cases, it may be possible to add other assurance in Zone 2.
- Zone 3: No matter how advanced the technology used, the level of identity binding assurance achieved in Zone 3 cannot exceed the level achieved in Zone 2. 4. The further you move identity binding to the left (meaning the earlier in the process), the higher the assurance and the lower the risk of fraud. At the same time, it is necessary to consider the tradeoff between increased security and increased friction (or exclusion), and weigh that against the context of the public health risk.
Our primary goal is to solve use cases for global travel.
These credentials will need to cover COVID-19 health status:
- Vaccination status.
- Status of Test result
Terms of Reference
Responsibilities and Deliverables
- What types of identity bindings should be standardized in the Good Health Pass ecosystem?
- What IAL is required for the individual’s identity document(s) presented to the health service provider?
- What AAL is required to bind the individual’s identity to the identity document(s) presented to the health provider for issuance of a Good Health Pass credential?
- What IAL is required for the identity document(s) the individual presents to the verifier of a Good Health Pass credential (e.g., airline, border, school, employer)?
- What AAL is required to bind the individual’s identity to the identity document(s) presented to the verifier?
- How should identity binding for paper credentials relate to identity binding for digital credentials?
- Bryn Robinson-Morgan (Mastercard)
- Paco Garcia (Yoti)
- Todd Gehrke
Only members of the Trust Over IP Foundation who have signed the necessary agreements and charters are permitted to participate in this Drafting Group and contribute to its deliverables.
Please add your name to the list below to indicate you have joined the Drafting Group:
The Drafting Group meets Weekly on Tuesday at 8:30 - 9:30 PT / 15:30 - 16:30 UTC.
Please find agendas, presentations, notes and recordings for all Drafting Group meetings HERE.
The Slack channel for this Drafting Group (trustoverip.slack.com) is #ghp-wg-identity-binding