This text is meant purely as a documentation tool and has no legal effect. The Union's institutions do not assume any liability for its contents. The authentic versions of the relevant acts, including their preambles, are those published in the Official Journal of the European Union and available in EUR-Lex. Those official texts are directly accessible through the links embedded in this document

laying down technical specifications and rules for the implementation of the trust framework for the EU Digital COVID Certificate established by Regulation (EU) 2021/953 of the European Parliament and of the Council

The technical specifications for the EU Digital COVID Certificate laying down the generic data structure, the encoding mechanisms, and the transport encoding mechanism in a machine-readable optical format are set out in Annex I.

The rules for populating the certificates referred to in Article 3(1) of Regulation (EU) 2021/953 are set out in Annex II to this Decision.

The requirements laying down the common structure of the unique certificate identifier are set out in Annex III.

The governance rules applicable to public key certificates in relation to the EU Digital COVID Certificate gateway supporting the interoperability aspects of the trust framework are set out in Annex IV.

A common coordinated data structure for the data to be included in certificates referred to in Article 3(1) of Regulation (EU) 2021/953, using a JavaScript Object Notation (JSON) schema, is set out in Annex V to this Decision.

This Decision shall enter into force on the day of its publication in the Official Journal of the European Union.

Generic data structure, encoding mechanisms and transport encoding mechanism in a machine-readable optical format (hereinafter called ‘QR’)

The technical specifications set out in this Annex contain a generic data structure and encoding mechanisms for the EU Digital COVID Certificate (‘DCC’). They also specify a transport encoding mechanism in a machine-readable optical format (‘QR’), which can be displayed on the screen of a mobile device or printed out. The electronic health certificate container formats of these specifications are generic, but in this context used to carry the DCC.

For the purpose of this Annex, ‘issuers’ means organisations using these specifications for issuing health certificates and ‘verifiers’ means organisations accepting health certificates as proof of health status. ‘Participants’ means issuers and verifiers. Some aspects set out in this Annex must be coordinated between the participants, such as the management of a namespace and the distribution of cryptographic keys. It is assumed that a party, hereafter referred to as the ‘Secretariat’, carries out these tasks.

The Electronic Health Certificate Container Format (‘HCERT’) is designed to provide a uniform and standardised vehicle for health certificates from their different issuers (‘issuers’). The objective of these specifications is to harmonise how those health certificates are represented, encoded and signed with the goal of facilitating interoperability.

The ability to read and interpret a DCC issued by any issuer requires a common data structure and agreement on the significance of each data field of the payload. To facilitate such interoperability, a common coordinated data structure is defined through the use of a ‘JSON’ schema that constitutes the framing of the DCC.

The payload is structured and encoded as a CBOR with a COSE digital signature. This is commonly known as a "CBOR Web Token" (CWT), and is defined in RFC 8392 ( 1 ). The payload, as defined in the following sections, is transported in a hcert claim.

The integrity and authenticity of origin of payload data must be verifiable by the verifier. To provide this mechanism, the issuer must sign the CWT using an asymmetric electronic signature scheme as defined in the COSE specification (RFC 8152 ( 2 )).

The Signature Algorithm (alg) parameter indicates what algorithm is used for the creating the signature. It must meet or exceed current SOG-IS guidelines as summarised in the following paragraphs.

One primary and one secondary algorithm is defined. The secondary algorithm should only be used if the primary algorithm is not acceptable within the rules and regulations imposed on the issuer.

In order to ensure the security of the system, all implementations have to incorporate the secondary algorithm. For this reason, both the primary and the secondary algorithm must be implemented.

The Key Identifier (kid) claim indicates the Document Signer Certificate (DSC) containing the public key to be used by the verifier for checking the correctness of the digital signature. Public key certificate governance, including requirements for DSCs, is described in Annex IV.

The Key Identifier (kid) claim is used by verifiers for selecting the correct public key from a list of keys pertaining to the issuer indicated in the Issuer (iss) Claim. Several keys may be used in parallel by an issuer for administrative reasons and when performing key rollovers. The Key Identifier is not a security-critical field. For this reason, it may also be placed in an unprotected header if required. Verifiers must accept both options. If both options are present, the Key Identifier in the protected header must be used.

Due to the shortening of the identifier (for size limitation reasons) there is a slim but non-zero chance that the overall list of DSCs accepted by a verifier may contain DSCs with duplicate kids. For this reason, a verifier must check all DSCs with that kid.

The Issuer (iss) claim is a string value that may optionally hold the ISO 3166-1 alpha-2 Country Code of the entity issuing the health certificate. This claim can be used by a verifier to identify which set of DSCs to use for verification. The Claim Key 1 is used to identify this claim.

The Expiration Time (exp) claim shall hold a timestamp in the integer NumericDate format (as specified in RFC 8392 ( 4 ), section 2) indicating for how long this particular signature over the payload shall be considered valid, after which a verifier must reject the payload as expired. The purpose of the expiry parameter is to force a limit of the validity period of the health certificate. The Claim Key 4 is used to identify this claim.

The Issued At (iat) claim shall hold a timestamp in the integer NumericDate format (as specified in RFC 8392 ( 5 ), section 2) indicating the time when the health certificate was created.

Verifiers may apply additional policies with the purpose of restricting the validity of the health certificate based on the time of issue. The Claim Key 6 is used to identify this claim.

The Health Certificate (hcert) claim is a JSON (RFC 7159 ( 6 )) object containing the health status information. Several different types of health certificate may exist under the same claim, of which the DCC is one.

The JSON is purely for schema purposes. The representation format is CBOR, as defined in (RFC 7049 ( 7 )). Application developers may not actually ever decode, or encode to and from the JSON format, but use the in-memory structure.

Strings in the JSON object should be normalized according to the Normalization Form Canonical Composition (NFC) defined in the Unicode standard. Decoding applications should however be permissive and robust in these aspects, and acceptance of any reasonable type conversion is strongly encouraged. If non-normalised data is found during decoding, or in subsequent comparison functions, implementations should behave as if the input is normalised to NFC.

The process starts with extraction of data, for example, from a Health Data Repository (or some external data source), structuring the extracted data according to the defined DCC Schemas. In this process, conversion to the defined data format and transformation for human readability may take place before the serialization to CBOR starts. The acronyms of the claims shall be mapped in every case to the display names before serialization and after deserialization.

Optional national data content is not allowed in certificates issued following the Regulation (EU) 2021/953 ( 8 ). The data content is limited to the defined data elements in the minimum data set specified in the Annex to Regulation 2021/953.

For arbitrary data interfaces, the HCERT container and its payloads may be transferred as-is, utilising any underlying, 8 bit safe, reliable data transport. These interfaces may include Near-Field Communication (NFC), Bluetooth or transfer over an application layer protocol, for example transfer of an HCERT from the Issuer to a holder’s mobile device.

If the transfer of the HCERT from the Issuer to the holder is based on a presentation-only interface (for example, SMS, email), the raw transport encoding is obviously not applicable.

To lower size and to improve speed and reliability in the reading process of the HCERT, the CWT shall be compressed using ZLIB (RFC 1950 ( 9 )) and the Deflate compression mechanism in the format defined in RFC 1951 ( 10 ).

In order to better handle legacy equipment designed to operate on ASCII payloads, the compressed CWT is encoded as ASCII using Base45 before being encoded into a 2D barcode.

The QR format as defined in (ISO/IEC 18004:2015) shall be used for 2D barcode generation. An error correction rate of ‘Q’ (around 25 %) is recommended. Because Base45 is used, the QR code has to use Alphanumeric encoding (Mode 2, indicated by the symbols 0010).

In order for verifiers to be able to detect the type of data encoded and to select the proper decoding and processing scheme, the Base45 encoded data (as per this specification) shall be prefixed by the Context Identifier string “HC1:”. Future versions of this specification that impact backwards-compatibility shall define a new Context Identifier, whereas the character following “HC” shall be taken from the character set [1-9A-Z]. The order of increments is defined to be in that order, i.e., first [1-9] and then [A-Z].

The optical code is recommended to be rendered on the presentation media with a diagonal size between 35 mm and 60 mm to accommodate readers with fixed optics where the presentation media is required to be placed on the surface of the reader.

If the optical code is printed on paper using low-resolution (< 300 dpi) printers, care must be taken to represent each symbol (dot) of the QR code exactly square. Non-proportional scaling will result in some rows or columns in the QR having rectangular symbols, which will hamper readability in many cases.

Each Member State is required to provide a list of one or more Country Signing Certificate Authorities (CSCAs) and a list of all valid Document Signer Certificates (DSCs), and keep these lists current.

As of this version of the specifications, Member States shall not assume that any Certificate Revocation List (CRL) information is used; or that the Private Key Usage Period is verified by implementors.

Instead, the primary validity mechanism is the presence of the certificate on the most recent version of that certificate list.

Member States can use a separate CSCA – but may also submit their existing eMRTD CSCA certificates and/or DSCs; and may even chose to procure these from (commercial) trust centres – and submit these. However, any DSC must always be signed by the CSCA submitted by that Member State.

When designing a scheme using this specification, Member States shall identify, analyse and monitor certain security aspects.

The issuer of HCERTs is required to limit the validity period of the signature by specifying a signature expiry time. This requires the holder of a health certificate to renew it at periodic intervals.

The acceptable validity period may be determined by practical constraints. For example, a traveller may not have the possibility to renew the health certificate during a trip overseas. However, it may also be the case that an issuer is considering the possibility of a security compromise of some sort, which requires the issuer to withdraw a DSC (invalidating all health certificates issued using that key which is still within their validity period). The consequences of such an event may be limited by regularly rolling Issuer keys and requiring renewal of all health certificates, on some reasonable interval.

This specification relies heavily on strong cryptographic mechanisms to secure data integrity and data origin authentication. Maintaining the confidentiality of the private keys is therefore necessary.

The confidentiality of cryptographic keys can be compromised in a number of different ways, for instance:

In order to mitigate against the risks that the signing algorithm is found to be weak, allowing the private keys to be compromised through cryptanalysis, this specification recommends all participants to implement a secondary fallback signature algorithm based on different parameters or a different mathematical problem than the primary.

As regards the risks mentioned related to the issuers’ operating environments, mitigations measures to ensure effective control shall be implemented such as to generate, store and use the private keys in Hardware Security Modules (HSMs). Use of HSMs for signing health certificates is highly encouraged.

Regardless of whether an issuer decides to use HSMs or not, a key roll-over schedule should be established where the frequency of the key roll-overs is proportionate to the exposure of keys to external networks, other systems and personnel. A well-chosen roll-over schedule also limits the risks associated with erroneously issued health certificates, enabling an issuer to revoke such health certificates in batches, by withdrawing a key, if required.

These specifications may be used in a way that implies receiving data from untrusted sources into systems that may be of mission-critical nature. To minimise the risks associated with this attack vector, all input fields must be properly validated by data types, lengths and contents. The issuer signature shall also be verified before any processing of the contents of the HCERT takes place. However, the validation of the issuer Signature implies parsing the Protected Issuer Header first, in which a potential attacker may attempt to inject carefully crafted information designed to compromise the security of the system.

The signature of the HCERT requires a public key to verify. Member States shall make these public keys available. Ultimately, every verifier needs to have a list of all public keys it is willing to trust (as the public key is not part of the HCERT).

The system consists of (only) two layers; for each Member State one or more country level certificates that each signs one or more Document Signer Certificates that are used in day to day operations.

The Member State certificates are called Country Signing Certificate Authority (CSCA) certificates and are (typically) self-signed. Member States may have more than one (for example, in case of regional devolution). These CSCA certificates regularly sign the Document Signer Certificates (DSCs) used for signing HCERTs.

The “Secretariat” is a functional role. It shall regularly aggregate and publish the Member States’ DSCs, after having verified these against the list of CSCA certificates (which have been conveyed and verified by other means).

The resulting list of DSCs shall then provide the aggregated set of acceptable public keys (and the corresponding kids) that verifiers can use to validate the signatures over the HCERTs. Verifiers must fetch and update this list regularly.

Such Member State-specific lists may be adapted in the format for their own national setting. As such, the file format of this trust list may vary, for example, it can be a signed JWKS (JWK set format per RFC 7517 ( 11 ), section 5) or any other format specific to the technology used in that Member State.

In order to ensure simplicity, Member States may both submit their existing CSCA certificates from their ICAO eMRTD systems or, as recommended by the WHO, create one specifically for this health domain.

The key identifier (kid) is calculated when constructing the list of trusted public keys from DSCs and consists of a truncated (first 8 bytes) SHA-256 fingerprint of the DSC encoded in DER (raw) format.

Verifiers do not need to calculate the kid based on the DSC and can directly match the key identifier in issued health certificate with the kid on the trust list.

While patterned on best practices of the ICAO eMRTD PKI trust model, a number of simplifications shall be made in the interest of speed:

The general rules concerning the value sets established in this Annex aim to ensure interoperability on semantic level and shall allow uniform technical implementations for the EU Digital COVID Certificate. Elements contained in this Annex may be used for the three different settings (vaccination/testing/recovery), as provided for in Regulation (EU) 2021/953. Only elements with the necessity of semantic standardisation through coded value sets are listed in this Annex.

Translation of the coded elements into the national language are under the responsibility of the Member States.

For all data fields not mentioned in the following value set descriptions, encoding is described in Annex V.

If for any reason the preferred code systems listed below cannot be used, other international code systems may be used and advice on how to map the codes from the other code system to the preferred code system shall be put in place. Text (display names) may be used in exceptional cases as a backup mechanism when a suitable code is not available in the defined value sets.

Member States using other coding in their systems shall map such codes to the described value sets. Member States are responsible for any such mappings.

As some value sets based on the coding systems provided for in this Annex, such as those for vaccine and rapid antigen test coding, are changing often, they shall be published and regularly updated by the Commission with the support of the eHealth Network and the Health Security Committee. The updated value sets shall be published on the relevant website of the Commission, as well as on the webpage of the eHealth Network. A history of changes shall be provided.

1. Disease or agent targeted/Disease or agent from which the holder has recovered: COVID-19 (SARS-CoV-2 or one of its variants)

Code	Display	Code System name	Code System URL	Code System OID	Code System version
840539006	COVID-19	SNOMED CT	http://snomed.info/sct	2.16.840.1.113883.6.96	2021-01-31

Examples of codes that shall be used from the preferred code systems are the SNOMED CT code 1119305005 (SARS-CoV-2 antigen vaccine), 1119349007 (SARS-CoV-2 mRNA vaccine) or J07BX03 (covid-19 vaccines).

A value set setting out the codes to be used pursuant to the code systems established in this section shall be published and regularly updated by the Commission with the support of the eHealth Network. The value set shall be extended when new vaccine types are developed and put into use.

An example of a code that shall be used from the preferred code systems is EU/1/20/1528 (Comirnaty). An example of the name of the vaccine to be used as a code: Sputnik-V (standing for Sputnik V).

Vaccines shall be coded using an existing code in the published value set, even if their names are different in different countries. The reason is that there is no global vaccine registry covering all vaccines in current use yet. Example:

If this is not possible or advisable in a specific case, a separate code will be provided in the published value set.

An example of a code that shall be used from the preferred code system is ORG-100001699 (AstraZeneca AB). An example of the name of the organisation to be used as a code: Sinovac-Biotech (standing for Sinovac Biotech).

Different branches of the same Marketing Authorisation Holder or the same manufacturer shall use an existing code in the published value set.

As a general rule, for the same vaccine product, the code referring to its marketing authorisation holder in the EU shall be used, as there is no internationally agreed vaccine manufacturer or marketing authorisation holder registry yet. Examples:

If this is not possible or advisable in a specific case, a separate code will be provided in the published value set.

5. Number in a series of doses as well as the overall number of doses in the series

Where the person is receiving doses of the primary vaccination series, that is, the vaccination series intended to provide sufficient protection at an initial stage, (C) shall reflect the overall number of doses of the standard primary vaccination series (e.g. 1 or 2, depending on the type of vaccine administered). This includes the option of using a shorter series (C=1) where the vaccination protocol applied by a Member State provides for the administration of a single dose of a 2-dose vaccine to persons having previously been infected with SARS-CoV-2. A completed primary vaccination series shall thus be indicated by N/C = 1. For example:

Where the primary vaccination series is extended, for example for persons with severely weakened immune systems or where the recommended interval between primary doses has not been respected, any such doses shall be encoded as additional doses falling under Section 5.2.

Where the person is receiving doses following the primary vaccination series, such additional doses (X) shall be reflected in the corresponding certificates by increases in the number of doses administered (N) and overall number of doses (C) (resulting in (N+X)/(C+X)). For example:

Additional doses administered after the completion of the primary vaccination series shall thus be indicated by (N+X)/(C+X) = 1.

Vaccination certificates issued by 31 December 2021 shall continue to be accepted even if such certificates follow a different rule for encoding the number in a series of doses or the overall number of doses in the series. To ensure this, technical measures may be taken.

Within the legal framework established by Regulation (EU) 2021/953, Member States may take measures to address the situation of vulnerable groups who may receive additional doses as a matter of priority. For example, if a Member State decides to administer additional doses only to specific sub-groups of the population, it can choose, in accordance with Article 5(1) of Regulation (EU) 2021/953, to issue vaccination certificates indicating the administration of such additional doses only upon request and not automatically. Where such measures are taken, Member States shall inform the persons concerned accordingly, as well as that they may continue to make use of the certificate received following the completing of the standard primary vaccination series.

6. Member State or third country in which the vaccine was administered/test was carried out

Value set content: the complete list of 2-letter codes, available as a value set defined in FHIR (http://hl7.org/fhir/ValueSet/iso3166-1-2). If the vaccination or test was performed by an international organisation (such as UNHCR or WHO) and no information about the country is available, a code for the organisation shall be used. Such additional codes shall be published and regularly updated by the Commission with the support of the eHealth Network.

To be used in certificate 2, and certificate 3 if support for the issuance of recovery certificates based on types of test other than NAAT is introduced through a delegated act.

Code	Display	Code System name	Code System URL	Code System OID	Code System version
LP6464-4	Nucleic acid amplification with probe detection	LOINC	http://loinc.org	2.16.840.1.113883.6.1	2.69
LP217198-3	Rapid immunoassay	LOINC	http://loinc.org	2.16.840.1.113883.6.1	2.69

The content of the value set shall include the selection of rapid antigen test as listed in the common and updated list of COVID-19 rapid antigen tests, established on the basis of Council Recommendation 2021/C 24/01 and agreed by the Health Security Committee. The list is maintained by the JRC in the COVID-19 In Vitro Diagnostic Devices and Test Methods Database at: https://covid-19-diagnostics.jrc.ec.europa.eu/devices/hsc-common-recognition-rat

For this code system, relevant fields such as the identifier of the test device, name of the test and manufacturer shall be used, following the JRC structured format available at: https://covid-19-diagnostics.jrc.ec.europa.eu/devices

Code	Display	Code System name	Code System URL	Code System OID	Code System version
260415000	Not detected	SNOMED CT	http://snomed.info/sct	2.16.840.1.113883.6.96	2021-01-31
260373001	Detected	SNOMED CT	http://snomed.info/sct	2.16.840.1.113883.6.96	2021-01-31'

Each EU Digital COVID Certificate (DCC) shall include a unique certificate identifier (UCI) which supports the interoperability of the DCCs. The UCI may be used to verify the certificate. Member States shall be responsible for implementing the UCI. The UCI is a means to verify the veracity of the certificate and, where applicable, to link to a registration system (for example, an IIS). These identifiers shall also enable (paper and digital) assertions by the Member States that individuals have been vaccinated or tested.

The UCI shall follow a common structure and format easing human- and/or machine-interpretability of information and may relate to elements such as Member State of vaccination, the vaccine itself and a Member State specific identifier. It ensures flexibility to Member States to format it, in full respect of data protection legislation. The order of the separate elements follows a defined hierarchy that can enable future modifications of the blocks while maintaining its structural integrity.

The possible solutions for the composition of the UCI form a spectrum wherein the modularity and human-interpretability are the two main diversifying parameters and one fundamental characteristic:

The following overarching requirements shall be satisfied in relation to the UCI:

Backwards-compatibility shall be ensured: Member States that over time change the structure of their identifiers (within the main version, currently set at v1) shall ensure that any two identifiers that are identical represent the same vaccination certificate/assertion. Or, in other words, Member States cannot recycle identifiers.

The eHealth Network guidelines for verifiable vaccination certificates and basic interoperability elements ( 15 ) provide for different options available to Member States and other parties that may co-exist among different Member States. Member States may deploy such different options in different version of the UCI schema.

The secure and trusted exchange of signature keys for EU digital COVID certificates (DCCs) between Member States is realised by the EU Digital COVID Certificate Gateway (DCCG), which acts as a central repository for the public keys. With the DCCG, Member States are empowered to publish the public keys corresponding to the private keys that they use to sign digital COVID certificates. Relying Member States can use the DCCG to fetch up-to-date public key material on a timely basis. Later, the DCCG can be extended to exchange trustworthy supplementary information that the Member States provide, like validation rules for DCCs. The trust model of the DCC framework is a Public Key Infrastructure (PKI). Each Member State maintains one or more Country Signing Certificate Authority (CSCA), certificates of which are relatively long lived. Following the Member State’s decision, the CSCA may be the same or different than the CSCA used for machine-readable travel documents. The CSCA issues public key certificates for the national, short lived, Document Signers (i.e. signers for DCCs), which are called Document Signer Certificates (DSCs). The CSCA acts as a trust anchor such that relying Member States can use the CSCA certificate to validate the authenticity and integrity of the regularly changing DSCs. Once validated, Member States can provide these certificates (or just the public keys contained therein) to their DCC validation applications. Besides CSCAs and DSCs, the DCCG also relies on PKI to authenticate transactions, sign data, as the basis for authentication and as a means to ensure integrity of the communication channels between Member States and the DCCG.

Digital signatures can be used to achieve data integrity and authenticity. Public Key Infrastructures establish trust by binding public keys to verified identities (or issuers). This is necessary to allow other participants to verify the data origin and the identity of the communication partner and decide about trust. In the DCCG, multiple public key certificates are used for authenticity. This Annex defines which public key certificates are used and how they shall be designed in order to allow broad interoperability among Member States. It provides more details on the necessary public key certificates and it gives guidance on certificate templates and validity periods for Member States that want to operate their own CSCA. Since DCCs shall be verifiable for a defined timeframe (starting from the issuing, expire after a given time), it is necessary to define a verification model for all signatures applied on the public key certificates and the DCCs.

The following table contains abbreviations and terminology used throughout this Annex.

Term	Definition
Certificate	Or public key certificate. An X.509 v3 certificate that contains the public key of an entity
CSCA	Country Signing Certificate Authority
DCC	EU Digital COVID Certificate. A signed digital document that contains vaccination, test or recovery information
DCCG	EU Digital COVID Certificate Gateway. This system is used to exchange DSCs between the Member States
DCCGTA	The Trust Anchor certificate of the DCCG. The corresponding private key is used to sign the list of all CSCA certificates offline
DCCGTLS	The TLS server certificate of the DCCG
DSC	Document Signer Certificate. The Public Key Certificate of a Member State’s document signing authority (for example, a system that is allowed to sign DCCs). This certificate is issued by the CSCA of the Member State
EC-DSA	Elliptic Curve Digital Signature Algorithm. A cryptographic signature algorithm based on elliptic curves
Member State	Member State of the European Union
mTLS	Mutual TLS. The Transport Layer Security Protocol with mutual authentication
NB	National backend of a Member State
NBCSCA	The CSCA certificate of a Member State (could be more than one)
NBTLS	The TLS client authentication certificate of a national backend
NBUP	The certificate that a national backend uses to sign data packages that are uploaded to the DCCG
PKI	Public Key Infrastructure. Trust model based on public key certificates and certificate authorities
RSA	Asymmetric cryptographic algorithm based on integer factorization used for digital signatures or asymmetric encryption

This section gives an overview of the communication flows and security services in the DCCG system. It also defines which keys and certificates are used to protect the communication, the uploaded information, the DCCs, and a signed trust list that contains all onboarded CSCA certificates. The DCCG works as a data hub that allows the exchange of signed data packages for Member States.

Uploaded data packages are provided by the DCCG “as is”, meaning that the DCCG does not add or delete DSCs from the packages it receives. The national backend (NB) of the Member States shall be enabled to verify the end-to-end integrity and authenticity of the uploaded data. In addition to this, national backends and the DCCG will use mutual TLS authentication to establish a secure connection. This is in addition to the signatures in the data exchanged.

The DCCG uses Transport Layer Security (TLS) with mutual authentication to establish an authenticated encrypted channel between the Member State’s national backend (NB) and the Gateway environment. Therefore, the DCCG holds a TLS server certificate, abbreviated DCCGTLS, and the national backends hold a TLS client certificate – abbreviated NBTLS. Certificate templates are provided in Section 5. Every national backend can provide their own TLS certificate. This certificate will be whitelisted explicitly and thus may be issued by a publicly trusted certificate authority (for example, a certificate authority that follows the baseline requirements of the CA Browser Forum), by a national certificate authority or it can be self-signed. Every Member State is responsible for their national data and the protection of the private key used to establish the connection to the DCCG. The “bring your own certificate” approach requires a well-defined registration and identification process, as well as revocation and renewal procedures as described in sections 4.1 , 4.2 and 4.3. The DCCG uses a whitelist where the TLS certificates of NBs are added after their successful registration. Only NBs that authenticate themselves with a private key that corresponds to a certificate from the whitelist can establish a secure connection to the DCCG. The DCCG will also use a TLS certificate that allows the NBs to verify that they are indeed establishing a connection to the “real” DCCG and not some malevolent entity posing as DCCG. The certificate of the DCCG will be provided to the NBs after successful registration. The DCCGTLS certificate will be issued from a publicly trusted CA (included in all major browsers). It is the responsibility of the Member States to verify that their connection to the DCCG is secure (for example, by checking the fingerprint of the DCCGTLS certificate of the server connected to against the one provided post registration).

Member States taking part in the DCCG framework must use a CSCA to issue the DSCs. Member States may have more than one CSCA, for example, in case of regional devolution. Each Member State can either use existing certificate authorities or they can set up a dedicated (possibly self-signed) certificate authority for the DCC system.

Member States must present their CSCA certificate(s) to the DCCG operator during the official onboarding procedure. After successful registration of the Member State (see section 4.1 for more details), the DCCG operator will update a signed trust list that contains all CSCA certificates that are active in the DCC framework. The DCCG operator will use a dedicated asymmetric key pair to sign the trust list and the certificates in an offline environment. The private key will not be stored on the online DCCG system, such that a compromise of the online system does not enable an attacker to compromise the trust list. The corresponding trust anchor certificate DCCGTA, will be provided to the national backends during the onboarding process.

Member States can retrieve the trust list from the DCCG for their verification procedures. The CSCA is defined as the certificate authority that issues DSCs, hence Member States that use a multi-tier CA hierarchy (for example, Root CA -> CSCA -> DSCs) must provide the subordinary certificate authority that issues the DSCs. In this case, if a Member State uses an existing certificate authority, then the DCC system will ignore anything above the CSCA and whitelist only the CSCA as the trust anchor (even though it is a sub-ordinate CA). This is as the ICAO model, only allows for exactly 2 levels – a ‘root’ CSCA and a ‘leaf’ DSC signed by just that CSCA.

In case a Member State operates its own CSCA, the Member State is responsible for the secure operation and key management of this CA. The CSCA acts as the trust anchor for DSCs, and therefore protecting the private key of the CSCA is essential for the integrity of the DCC environment. The verification model in the DCC PKI is the shell model, which states that all certificates in the certificate path validation must be valid at a given time (i.e. the time of signature validation). Therefore, the following restrictions apply:

National backends can use the DCCG to upload and download digitally signed data packages after successful mutual authentication. In the beginning, these data packages contain the DSCs of the Member States. The key pair that is used by the national backend for the digital signature of uploaded data packages in the DCCG system is called national backend upload signature key pair and the corresponding public key certificate is abbreviated by NBUP certificate. Each Member State brings its own NBUP certificate, which can be self-signed, or issued by an existing certificate authority, such as a public certificate authority (i.e. a certificate authority that issues certificate in accordance with the CAB-Forum baseline requirements). The NBUP certificate shall be different from any other certificates used by the Member State (i.e. CSCA, TLS client or DSCs).

The Member States must provide the upload certificate to the DCCG operator during the initial registration procedure (see Section 4.1 for more details). Every Member State is responsible for their national data and it must protect the private key that is used for signing the uploads.

Other Member States can verify the signed data packages using the upload certificates that are provided by the DCCG. The DCCG verifies the authenticity and integrity of the uploaded data with the NB upload certificate before they are provided to other Member States.

Member States must register with the DCCG operator to take part in the DCCG system. This section describes the technical and operational procedure that must be followed to register a national backend.

The DCCG operator and the Member State must exchange information on technical contact persons for the onboarding process. It is assumed that the technical contact persons are legitimated by their Member States and identification/authentication is performed over other channels. For example, the authentication can be achieved when a Member State’s technical contact provides the certificates as password-encrypted files via email and shares the corresponding password with the DCCG operator via telephone. Also other secure channels defined by the DCCG operator may be used.

The Member State must provide three digital certificates during the registration and identification process:

All provided certificates must adhere to the requirements defined in Section 5. The DCCG operator will verify that the provided certificate adheres to the requirements of Section 5. After the identification and registration, the DCCG operator:

In case that a Member State wants to operate its own CSCA, the CSCA certificates may be self-signed certificates. They act as the trust anchor of the Member State and therefore the Member State must strongly protect the private key corresponding to the CSCA certificate’s public key. It is recommended that the Member States use an offline system for their CSCA, i.e. a computer system that is not connected to any network. Multi person control shall be used to access the system (for example, following the four eyes principle). After signing DSCs, operational controls shall be applied and the system that holds the private CSCA key shall be stored safely with strong access controls. Hardware Security Modules or Smart Cards can be used to further protect the CSCA private key. Digital certificates contain a validity period that enforces certificate renewal. Renewal is necessary to use fresh cryptographic keys and to adapt the key sizes when new improvements in computation or new attacks threaten the security of the cryptographic algorithm that is used. The shell model applies (see Section 3.2).

The following validity periods are recommended, given the one-year validity for digital COVID certificates:

For a timely renewal, the following usage periods for the private keys are recommended:

Member States must create new upload certificates and TLS certificates timely, for example, one month, before expiration in order to allow smooth operation. CSCA certificates and DSCs should be renewed at least one month before the private key usage ends (considering the necessary operational procedures). Member States must provide updated CSCA certificates, upload and TLS certificates to the DCCG operator. Expired certificates shall be removed from the whitelist and trust list.

Member States and the DCCG operator must keep track of the validity of their own certificates. There is no central entity that keeps record of the certificate validity and informs the participants.

In general, digital certificates can be revoked by their issuing CA using certificate revocation lists or Online Certificate Status Protocol Responder (OCSP). CSCAs for the DCC system should provide certificate revocation lists (CRLs). Even if these CRLs are currently not used by other Member States, they should be integrated for future applications. In case a CSCA decides not to provide CRLs, the DSCs of this CSCA must be renewed when CRLs become mandatory. Verifiers should not use OCSP for validation of the DSCs and should use CRLs. It is recommended that the national backend performs necessary validation of DSCs downloaded from the DCC Gateway and only forwards a set of trusted and validated DSC to national DCC validators. DCC validators should not perform any revocation checking on DSC in their validation process. One reason for this is to protect the privacy of DCC holders by avoiding any chance that the use of any particular DSC can be monitored by its associated OCSP responder.

Member States can remove their DSCs from the DCCG on their own using valid upload and TLS certificates. Removing a DSC means that all DCCs issued with this DSC will become invalid when Member States fetch the updated DSC lists. The protection of private key material corresponding to DSCs is crucial. Member States must inform the DCCG operator when they must revoke upload or TLS certificates, for example due to compromise of the national backend. The DCCG operator can then remove the trust for the affected certificate, for example by removing it from the TLS whitelist. The DCCG operator can remove the upload certificates from the DCCG database. Packages signed with the private key corresponding to this upload certificate will become invalid when national backends remove the trust of the revoked upload certificate. In case that a CSCA certificate must be revoked, Member States shall inform the DCCG operator as well as other Member States that they have trust relationships with. The DCCG operator will issue a new trust list where the affected certificate is not contained anymore. All DSCs issued by this CSCA will become invalid when Member States update their national backend trust store. In case that the DCCGTLS certificate or the DCCGTA certificate must be revoked, the DCCG operator and the Member States must work together to establish a new trusted TLS connection and trust list.

This section sets out cryptographic requirements and guidance as well as requirements on certificate templates. For the DCCG certificates, this section defines the certificate templates.

Cryptographic algorithms and TLS cipher suites shall be chosen based on the current recommendation from the German Federal Office for Information Security (BSI) or SOG-IS. These recommendations and the recommendations of other institutions and standardization organization are similar. The recommendations can be found in the technical guidelines TR 02102-1 and TR 02102-2 ( 16 ) or SOG-IS Agreed Cryptographic Mechanisms ( 17 ).

The requirements provided for in Annex I, Section 3.2.2 shall apply. Hence, it is strongly recommended that Document Signers use the Elliptic Curve Digital Signature Algorithm (ECDSA) with NIST-p-256 (as defined in appendix D of FIPS PUB 186-4). Other elliptic curves are not supported. Due to the space restrictions of the DCC, Member States should not use RSA-PSS, even if it is allowed as a fall back algorithm. In case that Member States use RSA-PSS, they should use a modulus size of 2048 or max. 3072 bit. SHA-2 with an output length of ≥ 256 bits shall be used as cryptographic hash function (see ISO/IEC 10118-3:2004) for the DSC signature.

For digital certificates and cryptographic signatures in the DCCG context, the major requirements on cryptographic algorithms and key length are summarized in the following table (as of 2021):

Signature Algorithm	Key size	Hash function
EC-DSA	Min. 250 Bit	SHA-2 with an output length ≥ 256 Bit
RSA-PSS (recommended padding) RSA-PKCS#1 v1.5 (legacy padding)	Min. 3000 Bit RSA Modulus (N) with a public exponent e > 2^16	SHA-2 with an output length ≥ 256 Bit
DSA	Min. 3000 Bit prime p, 250 Bit key q	SHA-2 with an output length ≥ 256 Bit

The recommended elliptic curve for EC-DSA is NIST-p-256 due to its widespread implementation.

The following table gives guidance on the NBCSCA certificate template if a Member State decides to operate its own CSCA for the DCC system.

Bold entries are required (must be included in the certificate), italic entries are recommended (should be included). For absent fields, no recommendations are defined.

Field	Value
Subject	cn= < non-empty and unique common name > , o= < Provider > , c= < Member State operating the CSCA >
Key usage	certificate signing, CRL signing (at minimum)
Basic Constraints	CA = true, path length constraints = 0

The subject name must be non-empty and unique within the specified Member State. The country code (c) must match the Member State that will use this CSCA certificate. The certificate must contain a unique subject key identifier (SKI) according to RFC 5280 ( 18 ).

The following table provides guidance on the DSC. Bold entries are required (must be included in the certificate), italic entries are recommended (should be included). For absent fields, no recommendations are defined.

Field	Value
Serial Number	unique serial number
Subject	cn= < non-empty and unique common name >, o= < Provider > , c= < Member State that uses this DSC >
Key Usage	digital signature (at minimum)

The DSC must be signed with the private key corresponding to a CSCA certificate that is used by the Member State.

In addition, the certificate should contain the CRL distribution point extension pointing to the certificate revocation list (CRL) that is provided by the CSCA that issued the DSC.

The DSC may contain an extended key usage extension with zero or more key usage policy identifiers that constrain the types of HCERTs this certificate is allowed to verify. If one or more are present, the verifiers shall verify the key usage against the stored HCERT. The following extendedKeyUsage values are defined for this:

Field	Value
extendedKeyUsage	1.3.6.1.4.1.1847.2021.1.1 for Test Issuers
extendedKeyUsage	1.3.6.1.4.1.1847.2021.1.2 for Vaccination Issuers
extendedKeyUsage	1.3.6.1.4.1.1847.2021.1.3 for Recovery Issuers

In absence of any key usage extension (i.e. no extensions or zero extensions), this certificate can be used to validate any type of HCERT. Other documents may define relevant additional extended key usage policy identifiers used with validation of HCERTs.

The following table provides guidance for the national backend upload certificate. Bold entries are required (must be included in the certificate), italic entries are recommended (should be included). For absent fields, no recommendations are defined.

Field	Value
Subject	cn= < non-empty and unique common name >, o= < Provider > , c= < Member State that uses this upload certificate >
Key Usage	digital signature (at minimum)

The following table provides guidance for the national backend TLS client authentication certificate. Bold entries are required (must be included in the certificate), italic entries are recommended (should be included). For absent fields, no recommendations are defined.

Field	Value
Subject	cn= < non-empty and unique common name >, o= < Provider > , c= < Member State on the NB >
Key Usage	digital signature (at minimum)
Extended key usage	client authentication ( 1.3.6.1.5.5.7.3.2)

The certificate may also contain the extended key usage server authentication ( 1.3.6.1.5.5.7.3.1), but it is not required.

Field	Value
Subject	cn = Digital Green Certificate Gateway (1) , o= < Provider > , c= < country >
Key Usage	digital signature (at minimum)
(1) The terminology of ‘Digital Green Certificate’ instead of ‘EU Digital COVID Certificate’ has been maintained in this context because this is the terminology which has been hardcoded and deployed in the certificate before the co-legislators decided on a new terminology.

Field	Value
Subject	cn= < FQDN or IP address of the DCCG > , o= < Provider > , c= < country >
SubjectAltName	dNSName: < DCCG DNS name > or iPAddress: < DCCG IP address >
Key Usage	digital signature (at minimum)
Extended Key usage	server authentication ( 1.3.6.1.5.5.7.3.1)

The certificate may also contain the extended key usage client authentication ( 1.3.6.1.5.5.7.3.2), but it is not required.

The TLS certificate of the DCCG shall be issued by a publicly trusted certificate authority (included in all major browsers and operating systems, following the CAB Forum baseline requirements).

This Annex establishes the technical data structure for EU Digital COVID Certificates (EUDCC), represented as a JSON schema. The document provides specific instructions related to the individual data fields.

The authoritative official JSON schema for EUDCC is made available at https://github.com/ehn-dcc-development/ehn-dcc-schema. Other locations are not authoritative, but may be used for preparing upcoming revisions.

By default, the current version as set out in this Annex and supported by all countries currently in production is shown under the indicated URL.

Upcoming next version, to be supported by a defined date by all countries, is shown under the indicated URL through version tagging, described more specifically in the Readme file.

An EU Digital COVID Certificate shall not be issued if not all data fields can be correctly populated in accordance with this specification due to missing information. This shall not be understood as affecting the obligation of Member States to issue EU Digital COVID Certificates.

Information in all fields may be provided using the full set of UNICODE 13.0 characters encoded using UTF-8, unless specifically restricted to value sets or narrower sets of characters.

Detailed information on individual groups and fields is provided in next sections.

Version information shall be provided. Versioning is following Semantic Versioning (semver: https://semver.org). In production, it shall be one of the officially released (current or one of the older officially released) versions. See Section JSON Schema location for more details.

Field id

Field name

Instructions

ver

Schema version

Shall match the identifier of the schema version used for producing the EUDCC.

Example:

"ver":"1.3.0"

Person name is the official full name of the person, matching the name stated on travel documents. The identifier of the structure is nam. Exactly 1 (one) person name shall be provided.

Field id	Field name	Instructions
nam/fn	Surname(s)	Surname(s) of the holder. Exactly 1 (one) non-empty field shall be provided, with all surnames included in it. In case of multiple surnames, these shall be separated by a space. Combination names including hyphens or similar characters must however stay the same. Examples: "fn":"Musterfrau-Gößinger" "fn":"Musterfrau-Gößinger Müller"
nam/fnt	Standardised surname(s)	Surname(s) of the holder transliterated using the same convention as the one used in the holder’s machine readable travel documents (such as the rules defined in ICAO Doc 9303 Part 3). Exactly 1 (one) non-empty field shall be provided, only including characters A-Z and <. Maximum length: 80 characters (as per ICAO 9303 specification). Examples: "fnt":"MUSTERFRAU<GOESSINGER" "fnt":"MUSTERFRAU<GOESSINGER<MUELLER"
nam/gn	Forename(s)	Forename(s), such as given name(s), of the holder. If the holder has no forenames, the field shall be skipped. In all other cases, exactly 1 (one) non-empty field shall be provided, with all forenames included in it. In case of multiple forenames, these shall be separated by a space. Example: "gn":"Isolde Erika"
nam/gnt	Standardised forename(s)	Forename(s) of the holder transliterated using the same convention as the one used in the holder’s machine readable travel documents (such as the rules defined in ICAO Doc 9303 Part 3). If the holder has no forenames, the field shall be skipped. In all other cases, exactly 1 (one) non-empty field shall be provided, only including characters A-Z and <. Maximum length: 80 characters. Example: "gnt":"ISOLDE<ERIKA"
dob	Date of birth	Date of birth of the DCC holder. Complete or partial date without time restricted to the range from 1900-01-01 to 2099-12-31. Exactly 1 (one) non-empty field shall be provided if the complete or partial date of birth is known. If the date of birth is not known even partially, the field shall be set to an empty string "". This should match the information as provided on travel documents. One of the following ISO 8601 formats shall be used if information on date of birth is available. Other options are not supported. YYYY-MM-DD YYYY-MM YYYY (The verifier app may show missing parts of the date of birth using the XX convention as the one used in machine-readable travel documents, e.g. 1990-XX-XX.) Examples: "dob":"1979-04-14" "dob":"1901-08" "dob":"1939" "dob":""

The JSON Schema supports three groups of entries encompassing certificate type specific information. Each EUDCC shall contain exactly 1 (one) group. Empty groups are not allowed.

Group identifier	Group name	Entries
v	Vaccination group	If present, shall contain exactly 1 (one) entry describing exactly 1 (one) vaccination dose (one dose).
t	Test group	If present, shall contain exactly 1 (one) entry describing exactly 1 (one) test result.
r	Recovery group	If present, shall contain exactly 1 (one) entry describing 1 (one) recovery statement.

Vaccination group, if present, shall contain exactly 1 (one) entry describing exactly one vaccination event (one dose). All elements of the vaccination group are mandatory, empty values are not supported.

Field id	Field name	Instructions
v/tg	Disease or agent targeted: COVID-19 (SARS-CoV or one of its variants)	A coded value from the value set disease-agent-targeted.json. This value set has a single entry 840539006, which is the code for COVID-19 from SNOMED CT (GPS). Exactly 1 (one) non-empty field shall be provided. Example: "tg":"840539006"
v/vp	COVID-19 vaccine or prophylaxis	Type of the vaccine or prophylaxis used. A coded value from the value set vaccine-prophylaxis.json. The value set is distributed from the EUDCC Gateway. Exactly 1 (one) non-empty field shall be provided. Example: "vp":"1119349007"(a SARS-CoV-2 mRNA vaccine)
v/mp	COVID-19 vaccine product	Medicinal product used for this specific dose of vaccination. A coded value from the value set vaccine-medicinal-product.json. The value set is distributed from the EUDCC Gateway. Exactly 1 (one) non-empty field shall be provided. Example: "mp":"EU/1/20/1528" (Comirnaty)
v/ma	COVID-19 vaccine marketing authorisation holder or manufacturer	Marketing authorisation holder or manufacturer, if no marketing authorization holder is present. A coded value from the value set vaccine-mah-manf.json. The value set is distributed from the EUDCC Gateway. Exactly 1 (one) non-empty field shall be provided. Example: "ma":"ORG-100030215"(Biontech Manufacturing GmbH)
v/dn	Number in a series of doses	Sequence number (positive integer) of the dose given during this vaccination event. 1 for the first dose, 2 for the second dose etc. More specific rules are provided in Section 5 of Annex II. Exactly 1 (one) non-empty field shall be provided. Examples: "dn":"1"(first dose) "dn":"2"(second dose) "dn":"3"(third dose)
v/sd	The overall number of doses in the series	Overall number of doses (positive integer) in the vaccination series. More specific rules are provided in Section 5 of Annex II. Exactly 1 (one) non-empty field shall be provided. Examples: "sd":"1" (in case of a 1-dose primary vaccination course) "sd":"2" (in case of a 2-dose primary vaccination series or for an additional dose following a 1-dose primary vaccination course) "sd":"3" (e.g. in case of additional doses following a 2-dose primary vaccination series)
v/dt	Date of vaccination	The date when the described dose was received, in the format YYYY-MM-DD (full date without time). Other formats are not supported. Exactly 1 (one) non-empty field shall be provided. Example: "dt":"2021-03-28"
v/co	Member State or third country in which the vaccine was administered	Country expressed as a 2-letter ISO3166 code (RECOMMENDED) or a reference to an international organisation responsible for the vaccination event (such as UNHCR or WHO). A coded value from the value set country-2-codes.json. The value set is distributed from the EUDCC Gateway. Exactly 1 (one) field shall be provided. Example: "co":"CZ" "co":"UNHCR"
v/is	Certificate issuer	Name of the organisation that issued the certificate. Identifiers are allowed as part of the name, but not recommended to be used individually without the name as a text. Max 80 UTF-8 characters. Exactly 1 (one) non-empty field shall be provided. Example: "is":"Ministry of Health of the Czech Republic" "is":"Vaccination Centre South District 3"
v/ci	Unique certificate identifier	Unique certificate identifier (UVCI) as specified in the https://ec.europa.eu/health/sites/default/files/ehealth/docs/vaccination-proof_interoperability-guidelines_en.pdf The inclusion of the checksum is optional. The prefix "URN:UVCI:" may be added. Exactly 1 (one) non-empty field shall be provided. Examples: "ci":"URN:UVCI:01:NL:187/37512422923" "ci":"URN:UVCI:01:AT:10807843F94AEE0EE5093FBC254BD813#B"

Test group, if present, shall contain exactly 1 (one) entry describing exactly one test result.

Field id	Field name	Instructions
t/tg	Disease or agent targeted: COVID-19 (SARS-CoV or one of its variants)	A coded value from the value set disease-agent-targeted.json. This value set has a single entry 840539006, which is the code for COVID-19 from SNOMED CT (GPS). Exactly 1 (one) non-empty field shall be provided. Example: "tg": "840539006"
t/tt	The type of test	The type of the test used, based on the material targeted by the test. A coded value from the value set test-type.json (based on LOINC). Values outside of the value set are not allowed. Exactly 1 (one) non-empty field shall be provided. Example: "tt": "LP6464-4"(Nucleic acid amplification with probe detection) "tt": "LP217198-3"(Rapid immunoassay)
t/nm	Test name (nucleic acid amplification tests only)	The name of the nucleic acid amplification test (NAAT) used. The name should include the name of the test manufacturer and the commercial name of the test, separated by a comma. For NAAT: the field is optional. For RAT: the field shall not be used, as the name of the test is supplied indirectly through the test device identifier (t/ma). When supplied, the field shall not be empty. Example: "nm": "ELITechGroup, SARS-CoV-2 ELITe MGB® Kit"
t/ma	Test device identifier (rapid antigen tests only)	Rapid antigen test (RAT) device identifier from the JRC database. Value set (HSC common list): — All Rapid antigen tests in HSC common list (human readable). — https://covid-19-diagnostics.jrc.ec.europa.eu/devices/hsc-common-recognition-rat (machine-readable, values of the field id_device included on the list form the value set). In EU/EEA countries, issuers shall only issue certificates for tests belonging to the currently valid value set. The value set shall be updated every 24 hours. Values outside of the value set may be used in certificates issued by third countries, however the identifiers shall still be from the JRC database. The use of other identifiers such as those provided directly by test manufacturers is not permitted. Verifiers shall detect values not belonging to the up to date value set and display certificates bearing these as invalid. If an identifier is removed from the value set, certificates including it may be accepted for a maximum of 72 hours after the date of removal. The value set is distributed from the EUDCC Gateway. For RAT: exactly 1 (one) non-empty field shall be provided. For NAAT: the field shall not be used, even if the NAA test identifier is available in the JRC database. Example: "ma": "344"(SD BIOSENSOR Inc, STANDARD F COVID-19 Ag FIA)
t/sc	Date and time of the test sample collection	The date and time when the test sample was collected. The time shall include information on the time zone. The value shall not denote the time when the test result was produced. Exactly 1 (one) non-empty field shall be provided. One of the following ISO 8601 formats shall be used. Other options are not supported. YYYY-MM-DDThh:mm:ssZ YYYY-MM-DDThh:mm:ss[+-]hh YYYY-MM-DDThh:mm:ss[+-]hhmm YYYY-MM-DDThh:mm:ss[+-]hh:mm Examples: "sc": "2021-08-20T10:03:12Z" (UTC time) "sc": "2021-08-20T12:03:12+02" (CEST time) "sc": "2021-08-20T12:03:12+0200" (CEST time) "sc": "2021-08-20T12:03:12+02:00" (CEST time)
t/tr	Result of the test	The result of the test. A coded value from the value set test-result.json (based on SNOMED CT, GPS). Exactly 1 (one) non-empty field shall be provided. Example: "tr": "260415000" (Not detected)
t/tc	Testing centre or facility	Name of the actor that conducted the test. Identifiers are allowed as part of the name, but not recommended to be used individually without the name as a text. Max 80 UTF-8 characters. Any extra characters should be truncated. The name is not designed for automated verification. For NAAT tests: exactly 1 (one) non-empty field shall be provided. For RAT tests: the field is optional. If provided, shall not be empty. Example: "tc": "Test centre west region 245"
t/co	Member State or third country in which the test was carried out	Country expressed as a 2-letter ISO3166 code (RECOMMENDED) or a reference to an international organisation responsible for carrying out the test (such as UNHCR or WHO). This shall be a coded value from the value set country-2-codes.json. The value set is distributed from the EUDCC Gateway. Exactly 1 (one) field shall be provided. Examples: "co": "CZ" "co": "UNHCR"
t/is	Certificate issuer	Name of the organisation that issued the certificate. Identifiers are allowed as part of the name, but not recommended to be used individually without the name as a text. Max 80 UTF-8 characters. Exactly 1 (one) non-empty field shall be provided. Examples: "is": "Ministry of Health of the Czech Republic" "is": "North-West region health authority"
t/ci	Unique certificate identifier	Unique certificate identifier (UVCI) as specified in the vaccination-proof_interoperability-guidelines_en.pdf (europa.eu) The inclusion of the checksum is optional. The prefix "URN:UVCI:" may be added. Exactly 1 (one) non-empty field shall be provided. Examples: "ci": "URN:UVCI:01:NL:187/37512422923" "ci": "URN:UVCI:01:AT:10807843F94AEE0EE5093FBC254BD813#B"

Recovery group, if present, shall contain exactly 1 (one) entry describing exactly one recovery statement. All elements of the recovery group are mandatory, empty values are not supported.

Field id	Field name	Instructions
r/tg	Disease or agent from which the holder has recovered: COVID-19 (SARS-CoV-2 or one of its variants)	A coded value from the value set disease-agent-targeted.json. This value set has a single entry 840539006, which is the code for COVID-19 from SNOMED CT (GPS). Exactly 1 (one) non-empty field shall be provided. Example: "tg": "840539006"
r/fr	Date of the holder’s first positive NAAT test result	The date when a sample for the NAAT test producing a positive result was collected, in the format YYYY-MM-DD (complete date without time). Other formats are not supported. Exactly 1 (one) non-empty field shall be provided. Example: "fr": "2021-05-18"
r/co	Member State or third country in which test was carried out	Country expressed as a 2-letter ISO3166 code (RECOMMENDED) or a reference to an international organisation responsible for carrying out the test (such as UNHCR or WHO). This shall be a coded value from the value set country-2-codes.json. The value set is distributed from the EUDCC Gateway. Exactly 1 (one) field shall be provided. Examples: "co": "CZ" "co": "UNHCR"
r/is	Certificate issuer	Name of the organisation that issued the certificate. Identifiers are allowed as part of the name, but not recommended to be used individually without the name as a text. Max 80 UTF-8 characters. Exactly 1 (one) non-empty field shall be provided. Example: "is": "Ministry of Health of the Czech Republic" "is": "Central University Hospital"
r/df	Certificate valid from	The first date on which the certificate is considered to be valid. The date shall not be earlier than the date calculated as r/fr + 11 days. The date shall be provided in the format YYYY-MM-DD (complete date without time). Other formats are not supported. Exactly 1 (one) non-empty field shall be provided. Example: "df": "2021-05-29"
r/du	Certificate valid until	The last date on which the certificate is considered to be valid, assigned by the certificate issuer. The date shall not be after the date calculated as r/fr + 180 days. The date shall be provided in the format YYYY-MM-DD (complete date without time). Other formats are not supported. Exactly 1 (one) non-empty field shall be provided. Example: "du": "2021-11-14"
r/ci	Unique certificate identifier	Unique certificate identifier (UVCI) as specified in the vaccination-proof_interoperability-guidelines_en.pdf (europa.eu) The inclusion of the checksum is optional. The prefix "URN:UVCI:" may be added. Exactly 1 (one) non-empty field shall be provided. Examples: "ci": "URN:UVCI:01:NL:187/37512422923" "ci": "URN:UVCI:01:AT:10807843F94AEE0EE5093FBC254BD813#B"

( 8 ) Regulation (EU) 2021/953 of the European Parliament and of the Council of 14 June 2021 on a framework for the issuance, verification and acceptance of interoperable COVID-19 vaccination, test and recovery certificates (EU Digital COVID Certificate) to facilitate free movement during the COVID-19 pandemic, OJ L 211, 15.6.2021, p. 1.

( 13 ) For implementation with QR codes, Member States could consider an extra set of characters up to a total length of 72 characters (including the 27-30 of the identifier itself) may be used to convey other information. The specification of this information is up to the Member States to define.

( 14 ) The Luhn mod N algorithm is an extension to the Luhn algorithm (also known as mod 10 algorithm) which works for numeric codes and is used for example for calculating the checksum of credit cards. The extension allows the algorithm to work with sequences of values in any base (in our case alpha characters).

( 15 ) https://ec.europa.eu/health/sites/default/files/ehealth/docs/vaccination-proof_interoperability-guidelines_en.pdf

		Official Journal
		No	page	date
►M1	COMMISSION IMPLEMENTING DECISION (EU) 2021/2014 of 17 November 2021	L 410	180	18.11.2021