Skapa en utfärdartjänst

CWT struktur

Biljettintygets innehåll transporteras i CWT "claims" som defineras efter behov. Engelskans "claim" kan översättas till fält, men båda definitioner används löpande i denna text. Intygets payload claims, header claims och signaturen utgör CWT biljetten. I Figuren nedan presenteras CWT strukturen för ett Covidbevis (Hcert). Mer info om claims finns i referensarkitekturen eller i RFC 8392.

För Covidbevis registrerades en publik claim hcert med claim key -260, som kan återanvändas för andra hälsointyg. Hcert är ett JSON-objekt (RFC 7159) som innehåller information om intyget.
Strängar i JSON objektet bör vara NFC normaliserade enligt Unicode-standarden.

Komma igång

Utfärdartjänsten ska hämta informationen som behövs för intyget och skapa en CBOR web token som är digitalt signerad genom COSE och representeras i en 2D kod.

Flöde för att generera 2D koden

JSON->CBOR->COSE->Zlib->Base45 + 2D kod

1: Skapa JSON dokument

Intygets information aggregeras ihop och skapas i JSON format.

Exempel JSON dokument av ett Covidbevis, se även eu-dcc-schema: Länk till annan webbplats.

2: CBOR

Intygets JSON dokument och övriga metadata sätts samman i ett set av CBOR Webtoken claims och kodas om till binär form.

3: COSE signering

COSE (CBOR Object Signing and Encryption) är en understandard till CBOR som tillhandahåller stöd för digital signering av CBOR-objekt. Signering utförs för att en Verifierare ska kunna säkerställa att CWT token är autentisk och inte har manipulerats. För att skapa en digital signatur behövs ett DSC certifikat och motsvarande privata nyckel.

4: Komprimera

För att minska storleken och förbättra hastigheten och tillförlitligheten vid läsning av 2D koden skall CWT:en komprimeras.

5: Generera Base45 + 2D kod

Base45 encoding används för att generera 2D koder eftersom den är en effektiv och robust metod för att representera binära data i en ASCII baserad sträng. Den använder en 45 teckens alfabet som består av siffror, bokstäver och ett par symboler. Detta gör att den kan representera data i en mindre mängd utrymme än andra kodningsmetoder.

Man kan lägga till ett prefix för att identifiera den alfanumeriska koden, exempelvis HC1 (Health Certificate 1). Detta gör att verifierare kan kunna upptäcka vilken typ av data som kodats och välja rätt avkodnings och bearbetningsschema, när det finns behov av att verifiera olika typer av intyg.

Referensprojekt

Det finns ett Java bibliotek som DIGG tagit fram för Covidbeviset som ligger på Github. Biblioteket användes för att skapa, signera och generera QR kod baserat på Hcert flödet.

DGC Java

Det finns liknande implementationer för C#, Python på eHealthnetworks Github. Detta är dock inte något som är testat av varken DIGG eller eHälsomyndigheten.

Bygga en utfärdartjänst

Steg 1 - Skapa projektet för utfärdartjänsten

• Gör en fork av DGC Java
• Testa att skapa, signera och generera en QR kod
• Refaktorera kod för nya intyget

Steg - 2 Lägg på fler funktioner

• Design av intyget (PDF mall)
• Persistering mot databad
• Hämtning av grunddata
• Användargränssnitt
• Distribution mot digital brevlåda

Länkar och dokumentation

• Referensarkitektur_biljettintyg (pdf) Pdf, 1.8 MB.
• eHealth Network: Digital Covid Certificates (github.com) Länk till annan webbplats.
• Electronic Health Certificates (github.com) Länk till annan webbplats.
• Digital Covid Certificate Schema (github.com) Länk till annan webbplats.
• EU eHealthNetwork Digital COVID Certificate valuesets (github.com) Länk till annan webbplats.
• Digital COVID Certificates: Business Rules (github.com) Länk till annan webbplats.
• An implementation in Java for creating and validating a EU Digital Covid Certificate (github.com) Länk till annan webbplats.