When a QR code was not a format.

1 min read

INTEROPERABILITY · 2021

What the COVID-19 certificate ecosystem revealed about compact data, digital signatures and cross-border verification.

During the pandemic, QR codes became a common visual language for presenting vaccination, test and recovery information. Their uniform appearance suggested standardisation: point a camera at a square and receive an answer.

The technical reality was considerably less uniform.

A QR code defines how information is placed into a two-dimensional symbol. It does not define the meaning of that information, how it is encoded, who signed it, where the corresponding verification key can be found, or which rules should be applied after verification.

By 2021, health certificates issued around the world were using the same visual carrier for markedly different systems. Building a scanner capable of recognising more than one of them was therefore not principally a camera problem. It was an interoperability problem.

One symbol, several technical stacks

PathCheck Foundation’s open-source Universal Verifier, also known as QR Check, attempted to bring several of those systems into a single mobile application. Its stated objective was broad verification coverage: scan a credential or pass, verify its cryptographic signature and present the result on an Android or iOS device.

The formats supported by the project reflected the fragmented landscape of the time. They included PathCheck’s own CRED format, DIVOC certificates used in India and Sri Lanka, SMART Health Cards used in the United States and Canada, the European HC1 Digital COVID Certificate, New York’s Excelsior Pass and ICAO Visible Digital Seals, among others.

These were not cosmetic variations of a common QR payload. Different formats used different prefixes, serialisations, compression methods, signature containers, key-discovery mechanisms and health-data models.

The application’s scanner exposed that distinction directly. A payload beginning with CRED: followed one verification path. One beginning with shc: followed another. HC1: selected the European DCC path. Binary or JSON-based codes required still other handlers. Before evaluating the contents, the verifier first had to determine what kind of object it had received.

The shared QR symbol was only the outermost layer.

What verification actually required

A useful way to understand the process is to separate its stages:

Read the symbol. Recover the characters or bytes encoded in the QR image.
Recognise the format. Identify the convention used to represent the certificate.
Decode and decompress. Reverse the transport encoding and, where applicable, compression.
Parse the structure. Reconstruct the signed object and its health-related payload.
Identify the signing key. Extract a key identifier or issuer and locate an appropriate public key.
Verify the signature. Establish whether the signed bytes have been altered and whether the signature matches the selected key.
Establish trust. Determine whether that key belongs to an issuer accepted for the relevant purpose.
Apply policy. Decide what the verified health information means in the place and at the time where it is presented.

These stages answer different questions. A correct signature establishes neither that the signer should be trusted nor that the holder satisfies a particular health rule. Conversely, a recognised issuer cannot make an altered payload valid.

This separation was particularly important when verification needed to work offline. The certificate and signature could travel together in the QR, but the verifier still needed a trustworthy and sufficiently current set of public keys. Offline operation removed dependence on a live response at the moment of scanning; it did not remove the need to distribute, update and govern trust information.

The Uruguayan case

In October 2021, the Universal Verifier added a specific path for QR certificates issued in Uruguay. The public code history shows a dedicated Uruguayan presentation component and changes that allowed the existing DCC decoder to distinguish the local payload from the then-current European schema.

Both travelled through a broadly similar cryptographic envelope, but their internal health-data structures were not identical. The generic European presentation expected the standard DCC name and event fields. The Uruguayan component handled a local structure containing a name, document type and number, and vaccination information organised by doses, dates and vaccine names.

Compatibility was enabled by material shared from Uruguay in the context of Interfase: examples of locally issued codes, together with analysis of the payload structure and the fields needed to interpret them. PathCheck contributors incorporated the corresponding handling into the Universal Verifier. The scope of the contribution was deliberately specific: helping the project understand and verify the Uruguayan case, rather than developing or maintaining the verifier as a whole.

This small episode illustrates an important characteristic of interoperability work. A format may be well documented in its place of origin and still remain effectively invisible elsewhere. Sometimes the missing element is not a new algorithm but a real sample, an explanation of local assumptions and someone able to connect both sides.

From local compatibility to a shared framework

The Uruguayan implementation subsequently moved into a wider interoperability framework. On 21 December 2021, the European Commission recognised Uruguay’s COVID-19 certificates as equivalent to the EU Digital COVID Certificate. Uruguay became the first South American country connected to that system.

The work described publicly by Uruguay’s digital-government agency included QR codes compatible with European specifications for vaccination, recovery and PCR-test information, together with a national backend connected securely to the European system for exchanging public keys.

In that framework, the compact HC1: representation used a deliberately layered construction. Health data was represented compactly with CBOR and carried in a CWT; the signed object used COSE; the resulting bytes were compressed, encoded with Base45 and finally placed in the QR symbol. A short key identifier allowed the verifier to select the public key needed to validate the signature.

Each layer addressed a different constraint:

Structured data needed an unambiguous representation.
The signature needed to survive printing, display and scanning.
The complete object needed to remain small enough for a practical QR code.
Verification needed to work without transmitting personal health data to a central service at each checkpoint.
Countries needed a governed mechanism for exchanging and updating signing keys.

The strength of the result did not come from the QR code alone. It came from the agreement surrounding every layer.

What the universal verifier exposed

The Universal Verifier was valuable not only as an application, but also as an informal interoperability laboratory. Bringing several formats into one codebase made their assumptions visible side by side.

Three observations remain useful beyond the pandemic.

A shared carrier is not a shared protocol

Visual similarity can conceal deep incompatibility. Two QR codes may require entirely different decoding, signature and trust procedures. Interoperability begins only when the parties agree on the complete chain, not simply on the use of QR.

Cryptographic validity and operational acceptance are separate

A verifier can establish that data was signed by a particular key and has not changed. Whether the issuer is authorised, whether its keys remain current, whether the certificate belongs to the presenter and whether the underlying event satisfies local rules are separate decisions.

Keeping those decisions separate makes implementations easier to reason about and policies easier to change without redesigning the cryptographic format.

Real examples reveal what specifications omit

Specifications describe intended behaviour. Real certificates expose character encoding, field interpretation, optional values, payload size, scanner behaviour and trust-distribution assumptions. The addition of Uruguay to the Universal Verifier was modest in code size, but it demonstrated the practical value of examining an actual artefact from another jurisdiction.

A temporary problem with lasting lessons

COVID-19 certificates belonged to an exceptional period, and many of the systems built around them are no longer central to daily life. The engineering questions they exposed remain current.

Whenever signed information must cross organisational or national boundaries, be carried in a compact visual medium and remain verifiable under imperfect connectivity, the same distinctions return: carrier versus format, signature versus trust, data versus policy, and specification versus implementation.

The QR code made the information portable. Cryptography made alteration detectable. Interoperability made the result useful beyond the system that issued it.

Context and contributions

PathCheck Foundation emerged from the MIT-led Safe Paths initiative and operated as an independent nonprofit supported by an international open-source community.

The Universal Verifier and its implementation were PathCheck projects. The contribution described here concerned the analysis of Uruguay’s certificate format and the local information needed to extend compatibility. It was made in the context of Interfase, with additional voluntary participation helping to connect that local analysis with the wider open-source effort.