eHealth Network

EU DCC Validation Rules

V1.00
2021-06-09
 eHealth Network

The eHealth Network is a voluntary network, set up under article 14 of Directive 2011/24/EU.
It provides a platform of Member States' competent authorities dealing with eHealth.

Adopted by consensus by the eHealth Network, online, 10.06.2021

2
-Keep this page free-
eHealth Network

Contents
1. Terminology................................................................................................................................... 4
2. Overview ........................................................................................................................................ 5
3. User Stories................................................................................................................................... 5
3.1 Departure ............................................................................................................................... 5
3.2 Arrival ..................................................................................................................................... 5
3.3 Booking .................................................................................................................................. 6
3.4 Holder Information ................................................................................................................ 6
3.5 Public Information................................................................................................................. 6
4. Principles ....................................................................................................................................... 6
4.1 Acceptance Rules ................................................................................................................ 6
4.2 Invalidation Rules ................................................................................................................. 7
4.3 Dates and Time Handling.................................................................................................... 7
5. Rule Processing ........................................................................................................................... 7
5.1 Overview ................................................................................................................................ 7
5.2 Processing Steps ................................................................................................................. 9
5.3 Selective Processing ......................................................................................................... 10
5.4 Fallback Scenarios ............................................................................................................. 10
5.4.1 Incompatible Rule Engine Versions ........................................................................ 10
5.4.2 Incompatible Schema ................................................................................................ 10
5.5 Rule Format and Repository............................................................................................. 11
5.5.1 Rule Identifier Pattern ................................................................................................ 11
5.5.2 Rule Format................................................................................................................. 11
5.5.3 Repository ................................................................................................................... 12
6. Rule and Valueset Distribution ................................................................................................. 12
6.1 Functional Overview .......................................................................................................... 12
6.2 Rules API ............................................................................................................................. 13
6.3 Valueset API ....................................................................................................................... 13
6.4 App Provisioning................................................................................................................. 13
7. Rules Engine ............................................................................................................................... 14
7.1 Overview .............................................................................................................................. 14
7.2 Rule Syntax ......................................................................................................................... 14
7.3 Dates and Time Handling.................................................................................................. 14
7.4 Basic Data Processing Structure ..................................................................................... 15
7.5 External Parameters .......................................................................................................... 15

4
eHealth Network

7.6 Validation Logic .................................................................................................................. 16

8. Predefined Rules ........................................................................................................................ 17
8.1 Available Data Fields ......................................................................................................... 17
8.2 Rules .................................................................................................................................... 18
Appendix A - examples ..................................................................................................................... 22
Appendix B .......................................................................................................................................... 22
Appendix C - CertLogic ..................................................................................................................... 23
Truthy and falsy .......................................................................................................................... 24
Literals: arrays, booleans, integers, and strings .................................................................... 24
Data access (var) ....................................................................................................................... 24
If-then-else (if) ............................................................................................................................. 25
Operations with binary operators ............................................................................................. 25
Negation (!).................................................................................................................................. 26
Offset datetime (plusDays) ....................................................................................................... 26
Reduction (reduce)..................................................................................................................... 26
Appendix D - multiple events checking ........................................................................................... 27
Multiple scans (for information only, and for discussion) ..................................................... 27
Todo list ....................................................................................................................................... 27

1. Terminology

DEFINITION DESCRIPTION

Technical Technical check (rules) on the authenticity, integrity,

check structure and time stamps of the QR code. These are not
included in these EU DCC Validation Rules.

Business Business rule validation checks on the DCC payload

Validation against acceptance and invalidation rules.

Verification Verifcation Datetime is the date+time against which the

Datetime rules are checked. For instance: date of departure, date
of arrival, current date etc.

CoD Country of Departure

5
eHealth Network

CoA Country of Arrival

DCC Digital COVID Certificate

FFT Fit for Travel, acceptance for access to a MS <<term may

change>>

MS Member State or Member States

Holder A Holder of a DCC.

Proof A cryptographically signed digital assertion of a

vaccination, test-results or recovery status of a holder.

Verifier A verifier uses trusted cryptographic informations of a

issuer to verify the proof of a holder.

Issuer The issuer issues or signes proofs about a holder

statement.

Rule Engine A rule engine processes rules over a set of data defined
in a standardized manner.

2. Overview
The EU DCC Validation Rules are applied on the payload of the HCert. All "technical"
validations have to be performed in the verifier applications to ensure that his checks are not
overriden. This includes:

 Check of EXP Date

 Check of the Data Format (CBOR, Schema)
 Check of the Cryptographic Signature

All checks which are based on the semantics of the payload, must be performed as a
Validation Rule to ensure the exchange/interoperability of this information to other countries
(hard coded rules on the payload cannot be explored by others). This should ensure the
following behaviour:

 All wallet apps of all countries must be able to evaluate the current rule set of a country
 All verifier apps of all countries must be able to evaluate the current rule set of a country
 External parties (e.g. Reopen Europe, Airlines, Websites) must be able to use the rules
as a input for checklists, visualizations etc.
 All verifier apps must be able to select a ruleset which has to be used for the checkup
against a scanned DCC
 All wallet apps must be able to select a ruleset which has to be used for the checkup
against a selected DCC

Under this site conditions, it's not recommended to implement hard coded rules on the
payload, otherwise this rules are "hidden" to others.

6
eHealth Network

3. User Stories

3.1 Departure

A user with the verifier app in the CoA wants to cross check, if a holder of DCC fulfils all
requirements of the CoA. The user opens the verifier app, selects the CoA (e.g. from the
boarding pass) and scans the provided DCC. The verifier app performs the technical
validation. If this validation was successful, the verifier app performs the logical validation by
checking the payload for additional rules set by the CoA. If all are passed, the verifier app
shows green and valid.

3.2 Arrival

A user with the verifier app in the CoA wants to cross check, if a holder of DCC fulfils all
requirements of the CoA. The user opens the verifier app. The CoA is his default setting for
scanning the provided DCCs. The verifier app performs the technical validation. If this
validation was successful, the verifier app performs the logical validation by checking the
payload for additional rules set by the CoA. If all are passed, the verifier app shows green
and valid.

3.3 Booking

The booking website needs to check before a successful booking the validity of a DCC. For
this purpose the service needs access to the logical rules to ensure the validity of the
provided data.

3.4 Holder Information

A holder of a DCCs needs to perform in the wallet app a check, if his current certificate is still
valid for entering a other memberstate. For this purpose, the user selects a certificate and
selects a member state to which the DCC should check against. The result is a list where all
rules are provided with green arrows or red crosses (included the most important technical
validations), that the user knows exactly what kind of actions he has to perform. For
instance: if the test certificate is not more valid, the checklist shows that the date time is
expired, but the type of the test is still ok. A holder must have all the time a full overview of
his current state.

3.5 Public Information

Some service providers want to visualize checklists or informations about the current
situation in a member state. This service providers are using the defined rules to create an
human readable presentation of the current situation. E.g. a visitor clicks on a state and gets
the actual rule set as checklist.

7
eHealth Network

4. Principles

4.1 Acceptance Rules

Acceptance Rules are all rules to generate acceptance for the digital green certificates. To
standardize the interpretation of a rule and the interoperability meaning, each defined rule
must respect the following principles:

1. The rules apply only for the trip from departure to arrival. After arrival, extra rules may
apply in the CoA, such as quarantine, extra tests et cetera. These are not in scope of the
FFT check.
2. Besides QR code data elements, the following external information elements are to be
used in the FFT check:
1. Verification DateTime (date and time against which the data in the QR code
are compared.). If no Verification DateTime is provided, it will be filled with the
current date and time.
2. Country of Destination (ISO 3166, 2-character)
Other external parameters such as age of the citizen, “color” of Country of
Origin are not in scope.
3. The QR code contains information on 1 event with one entry: either a vaccination, a
negative test, or a recovery statement (V, T or R).
4. The rules are checked against the Verification DateTime.
5. Rules must have a validity starting date and end date, indicating between witch time
points they are active. The end date may be open.
6. Only the active rules for the CoA are checked, and only the rules for the specific type of
certificate (V, T or R).
7. New rules come into effect at least 48 hours after they have been uploaded to the DCC
Gateway.
8. MS create their own set of rules. The EU rules are just for information and must be
included or edited in the MS rule set. This avoids unclarity or conflicting rules between
EU and MS rules: only MS rules will be processed.
9. All rules for a country are processed and all must resolve to true.
10. JSON Logic Syntax of a specified version is used to define the rules.

4.2 Invalidation Rules

Invalidation Rules are all rules defined by a issuing country to invalidate digital green
certificates. These rules can not be overriden by a verifier country and must be executed. To
standardize the interpretation of a rule and the interoperability meaning, each defined rule
must respect the following principles:

1. All rules from the issuing country must be processed.

2. The rules will be applied against the entire HCert payload.
3. JSON Logic Syntax of a specified version is used to define the rules.
4. GDPR Rules must be respected.

4.3 Dates and Time Handling

For a proper handling of any kind of rules an appropiate date and time handling is strictly
necessary. For this purpose the principles for handling dates and time are:

8
eHealth Network

1. The signing certificate expiration datetime supersedes the expiration datetime in the
Green certificate
2. Expiration datetime of the Green certificate supersedes the end date of the respective
V/T/R Dates
3. All used times inside the Green certificate must be timezoned for a proper comparement

5. Rule Processing

5.1 Overview

The basis for the rule processing is the default validation defined in the hCert Specification,
where a validator app scans a QR code and extracts the hCert Payload.

The rule processing is build on top of the standard data validation flow defined by the hCert
Specification. To ensure the maximum interoperability for applied rules between countries,
the processed payloads must meet the following criteria:

1. Each QR Code contains only one type of Proof (v/t/r)

2. The Proof contains only one event with one entry (v/t/r)
3. The Rule Engine processes only the QR Code Content and some external standardized
parameters

This guarantees a proper processing of rules on a single object without side effects or mixing
of edge cases. The validator and the wallet app can then be connected to a rule repository to
provide this information to fulfil the user stories described above.

9
eHealth Network

5.2 Processing Steps

The rule processing contains some common steps before the rules can be applied. At first
there must be a technical validation of the received certificate for expiration and schema
compatibility. If this is given, the process can continue with the rule engine checkup. Is the
engine supported (backwards compatibility must be given), then the processing can be
started. Otherwise a human readable feedback must be created. The second step is a
logical validation by the rules engine, which processes the rules with prepared data for a
certain certificate type. This prepared data must contain external data from the technical
environment, for instance the current time, the current country code for validation and other
standard values to give the rule engine a context for the verification.

10
eHealth Network

The output of the rules must be collected to get a full picture of the final result. This is
necessary for a proper feedback to the verification app which can handle then the complete
result matrix. The result matrix should contain at least the Rule Identifier, the current values
and the Boolean result value. In the case of a validation error, a verification application
(including the wallet) should feedback the validation result to the user similar to this table:

Rule
Rule Description Result Current
Identifier
Dose Number: 1
VR-XX- Number of doses must be
false
00123 2/2
Total Series of Doses: 2
VR-XX- vaccine medicinal product: Astra
Valid Vaccine True
00111 Zeneca

5.3 Selective Processing

The rule processing must be selectable in the wallet and in the verifier app to decide which
rules of which country has to be applied against a payload. For this purpose both apps must
have a selection by country to give the user the possibility to checkup against different rule
sets.

11
eHealth Network

5.4 Fallback Scenarios

5.4.1 Incompatible Rule Engine Versions

In the case of an incompatible engine version (rule engine version> current version), the
technical validation has to be performed a human readable fallback. This fallback can be a
table similar to this table:

RULE
RULE DESCRIPTION RESULT CURRENT
IDENTIFIER
Dose Number: 1
Number of doses must be
VR-XX-00123 OPEN
2/2
Total Series of Doses: 2
vaccine medicinal product: Astra
VR-XX-00111 Valid Vaccine OPEN
Zeneca

Each of the results has to be decided manually by the operator. For instance, by selecting
each row and give a check mark or by simply confirming that the check has successful
passed. This checkup is a completely manual checkup, because the engine is not able to
perform automatically a check with a rule.

This table can be presented similar to that table:

RULE
RULE DESCRIPTION RESULT CURRENT
IDENTIFIER
Dose Number: 1
Number of doses must be
VR-XX-00123 OPEN
2/2
Total Series of Doses: 2
vaccine medicinal product: Astra
VR-XX-00111 Valid Vaccine True
Zeneca

The wallet app should show the same table, but with a warning for each open rule, because
this can lead to time delays during the travel.

5.4.2 Incompatible Schema

In the case of a schema version provided by the DCC which is unknown or not supported by
the verification application, the verifier application can only present the complete content and
let the verifier decide.

5.5 Rule Format and Repository

5.5.1 Rule Identifier Pattern
5.5.5.1 Acceptance

Rule Prefix - Country Code - Unique Sequence Number

GR - EU - 0001

12
eHealth Network

"GR" for General Rule

"VR" for Vaccination Rule

ISO 3166 OR "EU" Incrementing Number
"TR" for Test Rule

"RR" for Recovery Rule

Table 6: Rule Identifier Format

5.5.5.2 Invalidation

The invalidation identifiers can be chosen, e.g. a GUID.

5.5.2 Rule Format

All rules are technically defined in a JSON format which describes the type, validity, the used
versions, the human readable descriptions etc. The table below describes which fields must
be present in the JSON to describing a rule.

FIELD DESCRIPTION DATATYPE EXAMPLE VALUES

Identifier The unique Rulename string GR-CZ-0001
Type Type of the Rule. string Acceptance/Invalidation
Version Version of the Rule string 1.0.0 (semver)
Version of the used
SchemaVersion string 1.0.0 (semver)
Schema
Engine Type of the RuleEngine string "CERTLOGIC"
Version of the used
EngineVersion string 2.0.1 (semver)
Engine
General, Test, Vaccination,
CertificateType Type of the certificate string
Recovery
Array of Human readable [{“lang”:“en”,desc:"Full
Description Array
description of the rule vaccination course 2/2"}]
ValidFrom Start Validity of the Rule string DateTime value
ValidTo End Validity of the Rule string DateTime value
Fields of the payload
AffectedFields which are used by the Array ["tg", "mn"...]
rule.
The logic payload in
Logic Object JSON
JSON.

An Example of the structure can be found in Appendix A

5.5.3 Repository

All rules are stored in a repository which must observe the validity time of a rule. The rules
for Invalidation and Acceptance are stored in separated sections of the repository. Is the

13
eHealth Network

"ValidTo" expired, the rule is automatically deleted, if the owner of the rule doesn’t update
the rule.

The repository performs content checks on the uploading/updating of rules to avoid

conflicts:

EXCEPTION IF NOT
CHECK DESCRIPTION
VALID
Check if the uploading Country uses the
Rule cannot be set for
UploaderCorrect right format for the identifier. Country is
another country.
extracted from Upload certificate.
The validFrom date must be minimum 48
Rule cannot be enabled
hours in the future on upload time. If the rule
RuleValidFrom within a time window
already exists, the valid from is taken from
less than 48 hours.
the old entry.
Rules with validity less
The validTo must be minimum five in the
RuleAlreadyExpired than 72 hours are not
future in relation to the validFrom date.
accepted.
Human Readable Description must be filled
Description must be
DescriptionFilled with minimum one entry with 20 signs and
filled for fallback.
language “en”.
VersionChecks The inserted Versions must be semVer Invalid Version Number
SchemaCheck The schema of the rule must be valid. Invalid Schema.
The language in the description array must
LanguageCheck Invalid Language.
be a valid one.

6. Rule and Valueset Distribution

6.1 Functional Overview

The rules and value sets are provided over the EU gateway additionally to the existing
functionality of up/downloading signer certificates. The rules can be uploaded by each
member state, but the value sets are maintained centrally by the eHN. In a future version the
value sets can be uploaded by the member state as well, but this needs further alignment
and harmonization of the value set interpretation.

14
eHealth Network

6.2 Rules API

RESPONSE
ROUTE ACTION DESCRIPTION PARAMETERS
CONTENT
Delivers an List of Array of CMS
/rules /{country} GET Country
Rules for a Country. Messages
/rules Upload/Update of a CMS
PUT -
/{ruleIdentifier} single Rule Message/RuleIdentifier
/rules
DELETE Deletes a rule. RuleIdentifier/Signature -
/{ruleIdentifier}
List of onboarded Array of
/countrylist GET -
Countries Country Codes

Note: The rules are immutable. After uploading it can be only deleted if a new version is
uploaded before.

6.3 Valueset API

RESPONSE
ROUTE ACTION DESCRIPTION PARAMETERS
CONTENT
ID List of available
/valuesets GET - JSON Array
Valuesets
Valueset for a ID as Path
/valueset/{id} GET JSON
certain ID Parameter

The valuesets will be placed as JSON on the server and will be published by a public route.

6.4 App Provisioning

The verifier and the wallet app get the business rules from a business rule backend which
downloads the rules from the gateway.

15
eHealth Network

7. Rules Engine

7.1 Overview

The rule engine has the task to prepare the extracted JSON payload for a standardized rule
processing. This contains a standardized container format, harmonized timestamps and the
insertion of external parameters to have a standardized set of parameters which are identical
across all rules and a standardized rule syntax.

7.2 Rule Syntax

The rule syntax is defined by JSON Logic1 which defines a set of operators in JSON format.
For this syntax are already implementations available in the most common languages. Some
of that languages differ in the interpretation of this syntax; therefore the behavior must be
always aligned. For this purpose, the CertLogic subset of the JsonLogic Syntax is defined to
align the behavior across all implementations. (see Appendix C)

7.3 Dates and Time Handling

The engine must convert all timestamps and dates to ISO8601 time zoned dates before
processing to ensure a proper comparing and calculation of date values. For this purpose,
the implementation must provide a custom operator “plusDays” to add and substract days of
a given date as in this proposal:

jsonLogic.add_operation("plusDays", function(date,days){

let d = new Date(Date.parse(date));

d.setDate(d.getDate() + days);

return d.toISOString();

});

1
https://jsonlogic.com/

16
eHealth Network

It has also been ensured that the implementation is able to realize the “between” operator for
dates correctly which is defined in the JSON Logic Javascript Version as a compare
operation between three values.

7.4 Basic Data Processing Structure

The basic data structure must follow a standardized manner to ensure that each rule defined
in a special version is processed correctly. This structure contains an block for external data
and the hCert content extracted by the rule engine. All rules are applied on this structure to
have an standardized syntax for each rule. The format is defined in JSON and the order of
the fields can be arbitary.

FIELD
DESCRIPTION FORMAT
NAME

Block for
external external JSON
parameters

JSON Payload
payload JSON
of the DCC

The payload contains the extracted entry of the certain certificate type (e.g. one entry of a
vaccination). If the type is “general” the payload contains the complete hCert.

7.5 External Parameters

All external parameters are inserted by the rule engine which extract these parameters from
the CWT, the app environment or from other available variables.

VALIDATION
PARAMETER DESCRIPTION TYPE VALUE
FIELDNAME

Evaluation
Timestamp
Date
which is used
Validation Time
to check the validationClock "2021-04-21T18:25:43-
Date (ISO 05:00"
validity
8106)
(Reference
Date)

17
eHealth Network

VALIDATION
PARAMETER DESCRIPTION TYPE VALUE
FIELDNAME

JSON
Object
Lists of values
with
defined by "disease-agent-
Value Sets valueSets string
each valueset targeted":["840539006"]
arrays of
id.
each
valueset.

Country Code
of country of String
Country Code interest (can countryCode (ISO "NL", "CZ",...
be CoA or 3166)
CoD)

The expiration
String
Expiration date of the "2022-04-21T18:25:43-
exp (ISO
Date certificate 05:00"
3166)
"exp" Field.

The issuing
String
date of the "2022-04-21T18:25:43-
Issuing Date iat (ISO
certificate "iat" 05:00"
3166)
field.

An example can be found at the end of this page in Appendix B.

JSON Logic Usage:

{ "in":[{"var":"hcert.v.0.tg"},{"var":"external.valueSets.disease-agent-targeted"}] }

7.6 Validation Logic

The validation logic must execute ALL rules for a specific country. All rules must be
processed to provide a complete overview about the state of a DCC. The final result MUST
be true or false (True=VALID, False=INVALID). A mixed state should not be allowed to
express the rules so strict as possible. The logical pattern is:

Result = AND[Rule1, Rule2,Rule3]

All rules must be created in a way that the result expresses one validation for one entity. For
instance, one rule for Vaccination Status, one rule for Validity Status. Conflicting Rules like
"Dose1/2"+"Dose2/2" should be avoided, because they cannot be applied on one certificate
in the same time (E.g. "CheckDoses" is one entity and can perform multiple checks inside).

18
eHealth Network

8. Predefined Rules

8.1 Available Data Fields

This list of datafields is currently available in the hCert Schema (version 1.0.1).

DATA
TYPE
FIELD ABBREVIATION

Target
Disease tg Vac/Test/Rec
Agent

Vaccine or
vg Vac
Prophylaxis

Vaccine
medicinal mp Vac
product

Marketing
Authorization ma Vac
Holder

Dose
dn Vac
Number

Total Series
sd Vac
of Doses

Date of
dt Vac
Vaccination

Country of
co Vac
Vaccination

Certificate
is Vac/Test/Rec
Issuer

Unique
Certificate
ci Vac/Test/Rec
Identifier:
UVCI

Type of Test tt Test

19
eHealth Network

DATA
TYPE
FIELD ABBREVIATION

NAA Test
nm Test
Name

RAT Test
name and ma Test
manufacturer

Date/Time of
Sample sc Test
Collection

Date/Time of
dr Test
Test Result

Test Result tr Test

Testing
tc Test
Centre

Country of
co Test
Test

ISO 8601
Date of First
fr Rec
Positive Test
Result

ISO 8601
Date:
df Rec
Certificate
Valid From

Certificate
du Rec
Valid Until

20
Appendix A - examples

{
"Identifier": "GR-CZ-0001",
“Version”:"1.0.0",
“SchemaVersion”:"1.0.0",
"Engine":"CERTLOGIC",
"EngineVersion":"1.0.0",
"Type":"Test",
"Description":"The Field “Doses” MUST contain number 2 OR 2/2.",
"ValidFrom":"2021-05-27T07:46:40Z",
"ValidTo":"2021-06-01T07:46:40Z",
"AffectedFields":["dt","nm"]
"Logic":{
"and": [
{“>=":[ {"var":“dt", "23.12.2012" ]}},
{“>=":[ {"var":“nm", "ABC" ]}}]
}

Appendix B

JSON Example before JSON-LOGIC Processing:

"external":{

"validationClock":"2021-10-21T18:25:43-05:00",

"valueSets" : {

"test-type":[...],

"test-result":["260415000","..."]

},

"countryCode":"CZ",

"exp":"2022-10-21T18:25:43-05:00"

},

"hCert":{

"v":[ {
eHealth Network

"tg": "840539006",
"tt": "LP6464-4",
"ma": "1331",
"sc": "2021-05-15T12:34:56Z",
"dr": "2021-05-16T12:45:01Z",
"tr": "260415000",
"tc": "Testing center 1",
"co": "RO",
"is": "Ministry of Health",
"ci": "URN:UVCI:01:RO:QW3L2LL66Q#4"

]
}

Appendix C - CertLogic

CertLogic specifies a subset of JsonLogic Syntax, where necessary extended with custom
operations - e.g. for correct handling of dates.

Regarding the relation of CertLogic with JsonLogic, and the DCC validation rules:

 Any DCC validation rule must be expressed according to CertLogic, and may
not use JsonLogic in a way that's inconsistent with CertLogic, or not provided for by
CertLogic. In particular, only JsonLogic constructs present in this CertLogic
specification may be used.
 The use of “truthy”/“falsy” values that are not already JSON Booleans is discouraged,
and limited. In particular, DCC-validation rules should evaluate to a JSON Boolean,
not to any “truthy”/“falsy”.
 The semantics of the validation rules may be expressed in CertLogic, but
are not (strictly) defined by it: all implementations should pass the unit tests
assertions defined for the validation rules, and should pass additional tests that
ascertain the intent of the validation rule.
 This specification can be expanded when the needs arises, but never shrunken.
 The intention is that CertLogic remains compatible with JsonLogic, but may expand
on JsonLogic when and where necessary.
 In the interest of testability and risk mitigation, CertLogic is kept as small and simple
as possible, without any “programmers' convenience”.

The semantics of CertLogic is that of a function which takes a CertLogic expression, a data
context, and returns a value. All three of these values are JSON values that must be self-
contained, and non-referential. This means that:

 These JSON values can be finitely serialised, and identically deserialised.

 JSON objects anywhere in any of these values have at most one incoming reference
(that of their parent), and no outgoing references, except to children.

CertLogic logical expressions are of the following form, except for data access (var) - see
below.

22
eHealth Network

{
"<operation id>": [
<first argument>,
<second argument>,
// ...
<last argument>
]
}

The CertLogic function always evaluates to some value, and never throws an
error. Operating on a value null evaluates to null in most, but not all, cases.

A JSON array evaluates to an array with every item evaluated separately. If a JSON
object (not an array) is not of the logical expression form above, and also not of the var-
form, it evaluates to itself.

Truthy and falsy

Allowed falsy values are: false, and null. Allowed truthy values are: true, any non-empty
array, and any object. Using other values that are “traditionally” falsy or truthy is regarded as
undefined behaviour.

The reason to do this is that JsonLogic has a notion of truthy/falsy that differs from the usual
JavaScript one, precisely to aid in cross-platform adoption. CertLogic restricts this notion
even further to avoid confusion, or unjust reliance on behaviour that's perceived
as “common” but isn't (cross-platform).

Literals: arrays, booleans, integers, and strings

The usual array, boolean, integer (as a subset of JavaScript's Number type), and string
literals are usable. Literal for the following (types of) values are not
allowed: objects, null, and dates.

A datetime (or timestamp) has to be constructed by performing a plusDays operation on a

string with 0 days added. This makes it possible to ensure consistent datetime
representations across platforms, without being able to implicitly rely on the behaviour of
native datetime types in combination with the other (allowed) operations.

Data access (var)

The data context can be accessed through an operation of the following form:

{ "var": "<path>" }

The <path> is a string containing a path that “drills down into” the current data context. It
must be composed of “path fragments” which are either “Lispy” words (starting with a word
character followed by any number of word or number characters, or hyphens), or
integers, and which are separated by periods (.). It must match the regular
expression /^((\w[\w\d-]*)|\d+)(\.((\w[\w\d-]*)|\d+))*$/.

In terms of most mainstream programming languages: if it is a variable/slot holding the

current data context, then { "var": "<path>" } essentially means it.<path>. Data access of
a null or non-existing value evaluates to null.

23
eHealth Network

An integer path fragment signifies array indexing. Array indices are 0-based, and accessing
a non-existing index evaluates to null.

The empty path "" serves as a shorthand for accessing the entire data context -
alternatively, you can read it as it (or this). The variant { "var": <integer index> } is
superfluous as { "var": "<integer index>" } achieves the same result. The variant which
provides a default value instead of a missing/null result is (currently) not allowed.

As noted before: the var data access operation is the only type of expression that can have a
non-array argument specification.

If-then-else (if)

Conditional logic can be implemented through an operation of the following form:

{
"if": [
<guard>,
<then>,
<else>
]
}

If the <guard> evaluates to a truthy value, then the <guard> expression is

evaluated, otherwise the <else> expression.

Operations with binary operators

The following binary operators from JavaScript are available: ===, and, >, <, >=, <=, in, +.

An operation with a binary operator has the following form:

{
"<operator>": [
<operand 1>,
<operand 2>,
...,
<operand n>
]
}

For the ===, in, and + operators, n must equal 2.

The in operator checks whether <operand 1> is a member of <operand 2>, which must be
an array - possibly empty. (This must be checked beforehand through other means.)

The and operator can be used variadically: it can have any number of operands greater than
1. An operation with the and operator returns its first operand that evaluates to a falsy
value, or the evaluation of the last value.

The comparison operators >, <, >=, <= (exempting equality ===) can be used in (the
customary) binary form, or in the ternary form, with n equal to 3. The ternary form

{
"<op>": [

24
eHealth Network

<operand 1>,
<operand 2>,
<operand 3>
]
}

has the following semantics: (<operand 1> <op> <operand 2>) and (<operand 2> <op>
<operand 3>). The operands must be comparable values: integers, strings, or datetimes.

Negation (!)

The negation operation takes one operand, and returns true if that operand's
falsy, and false if it's truthy.

Offset datetime (plusDays)

A datetime offset operation has the following form:

{
"plusDays": [
<operand that evaluates to a string with a datetime in the allowed format>,
<integer: the number of days to add (may be negative)>
]
}

This operation is the only way to construct datetime values.

Reduction (reduce)

A reduction operation has the following form:

{
"reduce": [
<operand>,
<lambda>,
<initial>
]
}

The <operand> must be an array - possibly non-empty. This must be checked beforehand
by other means. Often, the expression { "var": "<operand>.0" } can be used to check
that <operand> is a non-empty array.

The reduce operation is equivalent to a left-fold over the

array <operand> with <initial> prepended, using the provided <lambda> function. That
function is provided with a modified data context of the form { "current": <current>,
"accumulator": <accumulator> }, with the <current> equalling the items of the array (in that
order), and <accumulator> equalling the result of the left-fold so far. In
particular, the reduce of an empty-array <operand> evaluates to <initial>. This is essentially
equivalent to JavaScript's Array.reduce function.

All other special array operations can be implemented using (only) a reduce operation with a
suitable <lambda>.

25
eHealth Network

To be able to access values in the original data context, CertLogic may expand beyond
JsonLogic at some point by also adding a key-value pair with key "data" to the data object
passed to the <lambda>, whose value is the original data context.

Appendix D - multiple events checking

This is currently not in scope.

Multiple scans (for information only, and for discussion)

 At the EU level, only 1 QR code is to be scanned. At the MS level, scenarios can be

worked out where more than 1 QR code must be scanned. Examples:
o The requirement to show two Tests, with a certain interval
o A person that has had COVID-19 needs only 1 vaccination dosis
 For these use cases, and for maximum flexibility, a methodology called “Two Points”
can be used:
 FFT is reached when at least 2 points have been reached. The following rules apply:
 At the beginning of the FFT check, the FFT status is 0.
 MS decide on the weight of V, T and R for their acceptance rules. These can be 2, 1
or 0 or 4. OR: V/R/T = 2
 V: divide “nr of vaccinations” by “nr of complete course” and multiply by 2. Example:
“1/2” = 1 point, “1/1” or “2/2” = 2 points.
 T: If the weight = 1, then two tests are needed for a FFT status. If it is 2, then 1 test is
enough.
 R: If the weight = 1, then another proof is needed to reach the 2 points. If it is 2, the
recovery statement is enough for the FFT.

Todo list

 Add Rule Container format for Gateway

 Add Valueset Description for Gateway
 Add Wallet/Verifier Architecture Guide
 Add Checklist Design
 Add Architecture Proposals for API
 Add JSON Logic Definitions/Requirements

26