EU Digital COVID Certificate: Test Data Repository for Test Automation

About • Testing & Status • 2D Code • How to Contribute • Licensing

About

To automate the generation and validation tests of COSE/CBOR Codes and it's base45/2D Code representations, a lot of data has to be collected to ensure the variance of the tests. This respository was established to collect a lot of different test data and related test cases of different member states in a standardized manner. Each member state can generate a folder in this section.

Testing & Status

• If you found any problems, please create an Issue.
• Please make sure to review the issues to see if any other members states found issues with your provided test data.

2D Code

Test Procedure

The test procedure has the following steps:

1. Load RAW Data File X
2. Apply all test and validation rules to File X (from all countries).
3. If one rule fails, the RAW Data File X is highlighted with the related Validation Rule/TestName Fail Status.

Note: If some of the "EXPTECEDRESULT" values are not present, the steps in the tests run can be skipped. The related data can be removed then as well. E.g. if just a "Expireing" test is constructed, the "EXPECTEDEXPIRATIONCHECK" value can be set together with an "COSE" and "VALIDATIONCLOCK" raw object. All other fields are then not necessary.

Possible boolean variables set in EXPECTEDRESULTS:

• EXPECTEDSCHEMAVALIDATION: Decoded data is valid according to dgc-schema
• EXPECTEDDECODE: Data from input in CBOR can be decoded, and the contents match input from JSON
• EXPECTEDVERIFY: Data from input in COSE can be cryptographically verified, with signer's certificate from TESTCTX.CERTIFICATE
• EXPECTEDUNPREFIX: Data from input in PREFIX can be decoded, i.e. contains a valid prefix (e.g. HC1: for now), and is equal to input in BASE45
• EXPECTEDVALIDJSON: Data from input (i.e. 2DCODE or PREFIX) can be decoded (whole chain), and the contents match input from JSON
• EXPECTEDCOMPRESSION: Data from input in COMPRESSED can be decompressed (with ZLIB), and matches input in COSE
• EXPECTEDB45DECODE: Data from input in BASE45 can be decoded (from Base45), and matches input in COMPRESSED
• EXPECTEDPICTUREDECODE: Data from input in 2DCODE can be decoded (from Base64-encoded PNG), and matches input in PREFIX
• EXPECTEDEXPIRATIONCHECK: Data from input is valid when verifying at the moment defined in TESTCTX.VALIDATIONCLOCK
• EXPECTEDKEYUSAGE: Data from input in COSE can be verified, and the key usage (defined by the OIDs) from TESTCTX.CERTIFICATE matches the content (i.e. it is a test statement, vaccination statement, or recovery statement)

For all variables above:

• When not set, this specific validation step is not tested in this input file
• When set to true, this validation step should succeed
• When set to false, this validation step should fail

Gateway

To indidcate which gateway environment is available, the test data context should contain: GATEWAY-ENV:Array

Example:

GATEWAY-ENV:["ACC", "TST"]

Note: Prod Keys should not be uploaded.

Code Generation

NOTE: DESCRIPTION, VERSION are mandatory for all tests.

NOTE 2: CBOR objects that are maps (i.e., the Digital Green Certificate), have an undefined order. This means that the actual encodings between two objects containing the same elements may differ since the ordering may be different. Therefore the validation can not be as simple as comparing two byte arrays against each other. The best method is to decode both elements that are to be compared with the same decoder, encode both objects with the same encoder, and then compare.

Code Validation

NOTE: DESCRIPTION, VERSION are mandatory for all tests.

NOTE 2: CBOR objects that are maps (i.e., the Digital Green Certificate), have an undefined order. This means that the actual encodings between two objects containing the same elements may differ since the ordering may be different. Therefore the validation can not be as simple as comparing two byte arrays against each other. The best method is to decode both elements that are to be compared with the same decoder, encode both objects with the same encoder, and then compare.

NOTE 3: As CBOR objects, JSON objects are not ordered, and a plain string comparison of two objects can not be performed.

File Structure

/schema/[semver].json
/COMMON/2DCode/raw/[Number].json
[COUNTRY]/2DCode/raw/[Number].json

Variables

COUNTRY is defined as the country code by ISO 3166.

Number must be a unique number by country/type.

JSON Schema

A number which identifies the used schema (used in the RAW Data).

RAW Content

The JSON Content under RAW is defined as:

{
   "JSON": **JSON OBJECT**,
   "CBOR": **CBOR (hex encoded)**,
   "COSE": **COSE (hex encoded)**,
   "COMPRESSED": **COMPRESSED (hex encoded)**,
   "BASE45": **BASE45 Encoded compressed COSE**,
   "PREFIX": **BASE45 Encoded compressed COSE with Prefix HC(x):**,
   "2DCODE": **BASE64 Encoded PNG**,
   "TESTCTX":{
       "VERSION": **integer**,
       "SCHEMA": **string (USED SCHEMA, semver)**,
       "CERTIFICATE": **BASE64** ,
       "VALIDATIONCLOCK": **Timestamp**, (https://docs.jsonata.org/date-time-functions ISO8601)
       "DESCRIPTION": **string**,
       "GATEWAY-ENV":**Array**
   },
   "EXPECTEDRESULTS": {
       "EXPECTEDVALIDOBJECT": **boolean**,
       "EXPECTEDSCHEMAVALIDATION": **boolean**,
       "EXPECTEDENCODE": **boolean**,
       "EXPECTEDDECODE": **boolean**,
       "EXPECTEDVERIFY": **boolean**,
       "EXPECTEDCOMPRESSION": **boolean**,
       "EXPECTEDKEYUSAGE": **boolean**,
       "EXPECTEDUNPREFIX": **boolean**,
       "EXPECTEDVALIDJSON": **boolean**,
       "EXPECTEDB45DECODE": **boolean**,
       "EXPECTEDPICTUREDECODE": **boolean**,
       "EXPECTEDEXPIRATIONCHECK": **boolean**,
    }
}

Example:

{
    "JSON": {
        "ver": "1.0.0",
        "nam": {
            "fn": "Musterfrau-Gößinger",
            "fnt": "MUSTERFRAU

function [name] ([Decoded JSON Object]) {
    return [boolean]
}