Good Health Pass compliant implementations should have the option to securely and privately interact with any number of rules engines from any number of governance authorities to accommodate variations in policy and regulations.

Terms of Reference

The Good Health Pass ecosystem needs to provide a seamless and frictionless user experience. However, the Collaborative recognizes that in addition to variations in testing and vaccination procedures and data collection in different localities around the world, there will also be many variations in the rules and policies governing what tests and/or vaccinations are required where and for what purposes.

Making these rules and policies accessible to issuers, holders, and verifiers of Good Health Pass credentials may require the services of any number of rules engines. A rules engine is a network-accessible service that can be sent a machine-readable query (such as a flight itinerary) for evaluation. The rules engine determines the rules applicable to the query and then evaluates those rules to return a response (such as what COVID-19 tests and/or vaccinations required to complete that particular itinerary). A Good Health Pass implementation can then use that response to instruct the traveler.

Examples of rules engines include TravelDoc (ICTS) and the Timatic service, the latter of which is operated by the International Air Transport Association (IATA). The IATA Travel Pass app, for example, enables a user to input their itinerary and receive back an analysis of the visas, COVID-19 status credentials, and other travel restrictions or travel advisories that are necessary – or advised – for that itinerary. 

In some cases, under some trust/governance frameworks, a rules engine could first serve as a verifier of Good Health Pass credentials from authorized issuers and then as an issuer of a pass as a secondary credential to the traveler. This pass would be the only credential the traveller actually needs to present in a specific context (such as to board a plane). Conceptually, this is very similar to an airline agent checking all of your travel documents before issuing you a boarding pass, which is then the only credential needed to board the plane.

As noted in Challenge #2, however, such a secondary credential is typically accepted only by a particular verifier, for a particular purpose, and for a particular time period.

As with trust registries, rules engines can be deployed in a centralized model (a single, global database to provide all rules and reconciliations of conditions), a federated model (where one general rules engine delegates to other more specialized rules engines serving specific geographies or governance authorities), or a distributed model (a decentralized network of rules engine “nodes” that determine “consensus” based on multiple inputs).

To preserve privacy, rules engines in the Good Health Pass ecosystem should operate without the traveler needing to provide personal data whenever possible. In most cases, a rules engine does not need that information to provide prescriptive information (e.g., a border is closed, or a test is no longer accepted) or conditional evaluations, based on non-personally identifiable data elements in a query (for example “test=negative AND less than 72 hours PLUS vaccine=true”).

Responsibilities and Deliverables

Key Interoperability Questions That Must Be Answered

  1. How many governance authorities will need to define their own rule sets?
  2. Will rules engines be specific to geographies? Industries? Platforms?
  3. How will government authorities indicate their entities, places, or devices are authorized to issue test or vaccination certificates?
  4. How will rules be expressed such that they are semantically understandable to a rules engine?
  5. Will rules expression be standardized across GHP-compliant rules engines?
  6. How will developers and their applications be authorized to access rule sets and rules engines?
  7. Will a downloadable rules engine or SDK be made available?



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:

Meeting Schedule

The Drafting Group generally meets every weekday at 13:00 UTC.

Meeting Page

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-rules-engines 

  • No labels