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:
- Load RAW Data File X
- Apply all test and validation rules to File X (from all countries).
- 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.
Field | Definition |
---|---|
JSON | The JSON-encoding of the Digital Green Certificate payload |
CBOR | The CBOR-encoding of the Digital Green Certificate payload |
COSE | The CWT defined by the hCert Spec. |
COMPRESSED | A CWT compressed by zLib |
BASE45 | The base45 encoding of the compression. |
PREFIX | The base45 string concatenated with the Prefix (HC1 etc.) |
2DCODE | The base64 encoded PNG of a QR Code. |
TESTCTX | Testcontext with context information of the raw data. |
EXPECTEDRESULTS | A list of expected results to the testdata. |
Possible boolean variables set in EXPECTEDRESULTS
:
EXPECTEDSCHEMAVALIDATION
: Decoded data is valid according to dgc-schemaEXPECTEDDECODE
: Data from input inCBOR
can be decoded, and the contents match input fromJSON
EXPECTEDVERIFY
: Data from input inCOSE
can be cryptographically verified, with signer's certificate fromTESTCTX.CERTIFICATE
EXPECTEDUNPREFIX
: Data from input inPREFIX
can be decoded, i.e. contains a valid prefix (e.g.HC1:
for now), and is equal to input inBASE45
EXPECTEDVALIDJSON
: Data from input (i.e.2DCODE
orPREFIX
) can be decoded (whole chain), and the contents match input fromJSON
EXPECTEDCOMPRESSION
: Data from input inCOMPRESSED
can be decompressed (with ZLIB), and matches input inCOSE
EXPECTEDB45DECODE
: Data from input inBASE45
can be decoded (from Base45), and matches input inCOMPRESSED
EXPECTEDPICTUREDECODE
: Data from input in2DCODE
can be decoded (from Base64-encoded PNG), and matches input inPREFIX
EXPECTEDEXPIRATIONCHECK
: Data from input is valid when verifying at the moment defined inTESTCTX.VALIDATIONCLOCK
EXPECTEDKEYUSAGE
: Data from input inCOSE
can be verified, and the key usage (defined by the OIDs) fromTESTCTX.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
Test Number | Test | Mandatory Fields | Mandatory Test Context Fields | Variable |
---|---|---|---|---|
1 | Load RAW File and load JSON Object, validate against the referenced JSON schema in the test context(SCHEMA field). | JSON | SCHEMA | EXPECTEDVALIDOBJECT |
2 | Create CBOR from JSON Object. Validate against the CBOR content in the RAW File. See note 2 below. | JSON, CBOR | EXPECTEDENCODE |
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
Test Number | Test | Mandatory Fields | Mandatory Test Context Fields | Variable |
---|---|---|---|---|
1 | Load the picture and extract the prefixed BASE45content. | PREFIX , 2DCode | EXPECTEDPICTUREDECODE | |
2 | Load Prefix Object from RAW Content and remove the prefix. Validate against the BASE45 raw content. | PREFIX, BASE45 | EXPECTEDUNPREFIX | |
3 | Decode the BASE45 RAW Content and validate the COSE content against the RAW content. | BASE45, COSE | EXPECTEDB45DECODE | |
4 | Check the EXP Field for expiring against the VALIDATIONCLOCK time. | COSE | VALIDATIONCLOCK | EXPECTEDEXPIRATIONCHECK |
5 | Verify the signature of the COSE Object against the JWK Public Key. | COSE | JWK | EXPECTEDVERIFY |
6 | Extract the CBOR content and validate the CBOR content against the RAW CBOR content field. See note 2 below. | COSE,CBOR | EXPECTEDDECODE | |
7 | Transform CBOR into JSON and validate against the RAW JSON content. See note 3 below. | CBOR,JSON | EXPECTEDVALIDJSON | |
8 | Validate the extracted JSON against the schema defined in the test context. | CBOR,JSON | SCHEMA | EXPECTEDSCHEMAVALIDATION |
9 | The value given in COMPRESSED has to be decompressed by zlib and must match to the value given in COSE | COSE,COMPRESSED | EXPECTEDCOMPRESSION |
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
Validation Content (TBD)
Javascript validation rules which must be passed during the testing of a 2D Code of the country. Each rule is applied on the decoded JSON Content. The function body is defined as
function [name] ([Decoded JSON Object]) {
return [boolean]
}
Image Content
Contains images of the generated base45 contents(PNG).
Certificate Content
The public key to validate the data structure. This is defined as base64 encoded datastructure (PEM).
How to contribute
Contribution and feedback is encouraged and always welcome. For more information about how to contribute, the project structure, as well as additional contribution information, see our Contribution Guidelines. By participating in this project, you agree to abide by its Code of Conduct at all times.
Licensing
Copyright (C) 2021 T-Systems International GmbH and all other contributors
Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License.
You may obtain a copy of the License at https://www.apache.org/licenses/LICENSE-2.0.
Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the LICENSE for the specific language governing permissions and limitations under the License.