4 Konceptuell lösningsarkitektur

4.3.2 Terminologi

4.1 Roller inom intygshantering

Tillitsmodellen och rollerna som beskrivs i W3C Verifiable Credentials standarden är applicerbar även i intygslösningen runt Covidbevis och illustreras i nedan bild.

Utfärdare: Den myndighet/organisation som utställer, signerar och distribuerar intyget till innehavaren. Kan även återkalla/revokera ett intygs status. Distribuerar metadata i form av publika nycklar, regler mm till Verifierare genom ett Verifierbart dataregister (VDR).

Verifierare: Fysisk person eller automatisk digital tjänst som kräver bevis. Verifiering online genom API eller offline genom verifieringsapp som kontinuerligt synkar publika nycklar, regler etc. från en distribueringsnod (VDRen).

Innehavare: Individ eller organisation som intyget är utställt till.

4.2 Rättsliga förutsättningar

Respektive myndighet som ska införa en intygsinfrastruktur måste självständigt beakta de rättsliga förutsättningarna för att säkerställa att informationshanteringen sker i förenlighet med gällande rätt. I avsnitt 4.3 presenteras endast en konceptuell lösningsbeskrivning av de tjänster/förmågor som behövs för att hantera intyg.

Som ett exempel, kan vi referera till lösningen runt Covidbevis där E-hälsomyndigheten beslutade att en arkivering av intygen var nödvändig. Detta baserade man på Tryckfrihetsförordningen andra kapitel gällande att om man som myndighet expedierat en handling, så ska varje bevis/intyg arkiveras som en allmän handling. Det ska tilläggas att det finns olika definitioner av allmänna handlingar och i detta fallet är det alltså inte offentliga handlingar.

4.3 Beredskapshantering

Av de värdeerbjudanden som byggblocket föreslår, så är beredskapshanteringen det som innehåller tekniska förmågor och tjänster som föreslås hanteras centralt av ansvarig myndighet. Det gör att en konceptuell arkitektur runt dessa förmågor idag går att beskriva mer utförligt än exempelvis ett ramverk eller de förmågor som antas behövas runt ekosystemet runt EU-plånboken.

värdeerbjudande:

Nedan illustreras en konceptuell arkitektur baserad på systemet runt Covidbevis utifrån tekniska förmågor och grupperat enligt Ena ekosystemets grundroller. Byggblockets hypotes är att det kommer vara en sektorsansvarig myndighet som behöver hantera konsumentförmågor och en intygsansvarig myndighet som sätter upp och förvaltar/hanterar dem central förmågorna. Det kan också vara så att den sektorsansvariga myndigheten, exempelvis MSB, hanterar alla förmågor.

Klicka för att förstora bilden "Systemskiss Tekniska Förmågor"

Aktörer:

Administratör: Person inom ansvarig myndighet, som via en digital tjänst kan administrera, d.v.s. skapa eller revokera ett intyg.

Individer: Personer som kan beställa ett intyg via en e-tjänst (självprovisionering), genom att logga in med sin e-legitimation.

Förvaltning: Hanterar drift och utveckling av de centrala tjänsterna, samt statistik.

Verifierare: Kontrollerar intygs äkthet med en verifieringsapp som är synkad med metadata från VDRen.

4.3.1 Konsumentförmågor

Det finns ett värde i att abstrahera beredskapshanteringen i olika konsumentförmågor om det är olika aktörer inblandade i intygshanteringen. Även om det inte är tekniska anslutningar som krävs till de centrala tjänsterna som i föreslagen lösning inkluderar portaltjänster, så finns det ansvarsområden, rutiner och behörighetshantering som behöver tydliggöras. Tanken är att sektorsansvarig myndighet ansvarar för konsumentförmågorna då de har det övergripande ansvaret för intygsinfrastrukturen.

Hantera beredskapsprocess för intyg

Beredskapssektorsansvarig myndighet ansvarar för att etablera och underhålla en beredskapsprocess för intyget som innefattar ett antal aktiviteter och ansvariga aktörer. Det är rimligt att man tar fram simuleringar och kör tester tillsammans med de andra berörda aktörerna på årlig basis. Då kan man identifiera svagheter och eventuella oklarheter i ansvarsområden vilket leder till en minskad uppstartstid.

Exempel på beredskapsprocess i BPMN notation, där Digg och MSB är ingående aktörer:

Klicka här för att förstora bilden "Exempel beredskapsprocess"

Administrera intyg

Det finns individer som inte har någon e-legitimation, saknar mobil/dator eller på andra sätt hamnar i ett digitalt utanförskap. I en naturkatastrofsituation så har kanske individens tillhörigheter förstörts. Då krävs det ombud som kan skapa intyg åt individen. Beställning kan ske genom ett blankettförfarande eller genom att individen besöker ett servicecenter. För handläggningsärenden på plats via ett servicecenter krävs det rutiner för hantering såsom att identifiera individ, skapa ärende i ett ärendehanteringssystem.

Beställning via blankett

• Användaren införskaffar sig en beställningsblankett
  • Via nedladdning från webben
  • Via beställning från myndighetens kundtjänst
• Användaren fyller i och postar blankett till ansvarig myndighet
• Myndighetens personal hanterar blankett och utfärdartjänsten
  • Hämtar folkbokföringsuppgifter för komplett namn av den identifierade
  • Skapar och signerar ett intyg för den identifierade
  • Postar det till folkbokföringsadressen genom utskriftstjänsten

Utlämning via serviceombud

• Användaren kontaktar ett servicecenter för att begära ut ett intyg
• Användaren identifierar sig
• Ombudet loggar in i admintjänsten och utfärdandetjänsten
  • Hämtar folkbokföringsuppgifter för komplett namn av den identifierade
  • Skapar och signerar ett intyg för den identifierade
  • Ombudet lämnar ut intyget till den identifierade

Kontrollera/verifiera intyg

En kontrollant måste kunna kontrollera intygets äkthet offline. Detta är i synnerhet viktigt vid allvarliga kriser, då internet kan ligga ner i berörda områden. Metadata synkas automatiskt varje gång kontrollanten startar eller använder verifieringsappen, när internet/nätverket är tillgängligt. Inga personuppgifter skickas eller lagras lokalt i appen. I ett beredskapsscenario är det tveksamt att det behövs online validering genom API. Det har Sverige inte etablerat i Covidbevis projektet, men har använts i andra länder exempelvis för att checka in sig till flyg via en e-tjänst.

Nedan illustreras verifieringsflödet schematiskt:

Klicka här för att förstora bilden "Schematisk beskrivning av verifieringsflödet"

1. Innehavare presenterar intyget för Verifierare.
2. Verifierare öppnar appen eller startar mobilkamera för att skanna intyget.
3. Appen synkar publika nycklar och regler från Verifierbara dataregistret (VDRen).
4. QR koden skannas med mobilkameran.
5. QR koden avkodas och genomgår en verifieringsprocess. Verifieringsprocessen består i att först kontrollera certifikatets äkthet och giltighetstid. Sedan kontrolleras informationsmängden mot de regler som laddats ner från VDRen.
6. Negativt resultat visar inga personuppgifter, positivt resultat visar minimalt med information för att kunna verifiera individ mot ID handling. Resultatet döljs efter 60 s.
7. Verifieraren ser resultatet på skärmen och verifierar mot ID handlingen vid positivt utfall.
8. Om ID handling matchar uppgifterna i det positiva resultatet i verifieringen, så ges individen tillträde.

Revokera/återkalla intyg

En administratör i E-tjänsten behöver kunna revokera (återkalla) ett intyg om det visar sig att det utställts på felaktiga grunder eller på andra sätt förfalskats/förvanskats men har en giltig digital signatur.

Schematiskt flöde som beskriver hur förfarandet kan gå till:

• Ansvarig myndighet bli kontaktad
• Underlag för revokering tas fram
  • Anledning/orsak
  • Intygets unika ID
  • Kontaktuppgifter
• Skapar ett ärende
  • Myndigheten skapar ett ärende och dokumenterar ovanstående i ett ärende hanteringssystem. Det ska fungera för spårbarhet vid eventuella felhanteringar
• Verksamhet tar emot ärendet, analys påbörjas
  • Analys av ärendet
  • Kontakta personen som har inkommit med en begäran av revokering
  • Säker identifiering (via Bank ID eller blanket?)
  • Vid behov, kontakta den myndighetsinterna juristfunktionen hos den intygsutfärdade myndigheten
  • Verksamhet behöver besluta ifall anledningen/orsaken är tillräckligt för att kunna revokera samt efter att analysen är genomförd.
• En administratör revokerar intyget via admintjänsten
  • Intygets ID läggs till i spärrlistan i VDRen som verifieringsapparna synkar mot.

Analysera statistik

Det finns ett verksamhetsmässigt behov i att kunna analysera intygshanteringen och få ut statistik, så rätt beslut och prognoser kan tas och eventuellt avvikande mönster kan fångas in. Idag finns inte denna tjänsten i Covidbevislösningen, men det har hela tiden funnits ett stort behov av löpande statistik. Statistik inhämtas från loggar och databasen och sammanställs med skript. Det finns framtaget en konceptuell lösning på en statistiktjänst, men denna behöver utvecklas. Om man utgår från den konceptuella systemskissen i detta avsnitt, så skulle en intressent behöva ta hjälp av förvaltningen av intygstjänsten, som schemalägger en rapport som distribueras ut genom BI applikationen (Analysera förmågan i systemskissen). BI applikationen är något som förslagsvis tas från hyllan och redan används i myndigheten, exempel SAP BO eller Qlikview.

4.3.2 Centrala förmågor

Upprätthålla beredskap för intygsinfrastruktur

Ansvarig myndighet för uppsättning av de tekniska förmågorna behöver ha en etablerad rutin som utgår från en eller flera checklistor, samt referensprojekt för att så snabbt som möjligt kunna få upp driftsmiljöer vid en samhällskritisk händelse. Det är rimligt att vissa tjänster kanske redan behöver finnas etablerade, exempelvis de tekniska förmågor och processer som ligger i PKI infrastrukturen. Vet man vilken typ av intyg det är, om det behövs någon typ av bedömning som krävs före utfärdandet eller om individen kan skapa det själv via en e-tjänst, så går det att ta fram en prototyp i nästa utvecklingsfas. Målvisionen med förmågan är att i princip kunna ”trycka på en knapp” för att sätta upp intygsinfrastrukturen. 

Leverabler

• Checklista för beredskapshantering, med olika beredskapsnivåer (se bilaga)
• Referensprojekt för de olika tekniska förmågorna inom intygsinfrastrukturen:
  • Portaltjänster
  • Backendtjänster
  • PKI-tjänster
    • CA
    • VDR
  • Verifieringsapp
• Konfigurationsrepor för driftsmiljöer baserat på beredskapsnivå.

Verifiera intyg

Verifieringsappen till beredskapslösningen föreslås hanteras tillsammans med resten av de tekniska förmågorna. Tiden är en viktig faktor vid kritiska händelser och erfarenheterna från Covidbevisprojektet visade att det var tidskrävande att synka ändringar samt att testa med andra aktörer. Det finns flera tekniska implementationer av verifieringsappar som använts för att verifiera Covidbevis som finns som öppen källkod.

Verifieraren behöver en mobiltelefon med verifieringsappen som innehåller publika nyckeln, regler och spärr/revokeringslista för att kontrollera äkthet. För att kunna distribuera cert/publika nycklar, regler och revokeringslista till en verifierare behöver ”Utfärdaren” tillgängliggöra detta på en nod som appen kommer åt. Synkning mot noden sker automatiskt när ”appen” används, när internet är tillgängligt. Eventuellt finns det här behov av att titta på hur man kan distribuera denna data med längre avbrott i internetuppkoppling, exempelvis genom kurir och/eller manuell hantering på servicecenter.

Appen kontrollerar äktheten i intyget genom att skanna och avläsa innehållet i QR koden, samt att intyget inte finns i revokeringslistan. Det går att använda sig av regler (business rules) om utfärdaren vill göra snabba ändringar. Det kan exempelvis vara specifika tidpunkter då intyget är giltigt (08.00-16.30), eller att vissa områden tillfälligt behöver stängas av.

Tekniska förmågor

En verifieringsapp för Android och IOS för offline scenarios.

Referensappen för covidbevis har inte stöd för revokeringslösningen som tagits fram av EU. Det finns inte heller stöd för dynamisk hanteringen av verksamhetsregler som man får genom exempelvis Json logic eller Cert logic. Istället är reglerna hårdkodade i appen, vilket gör det svårare att fritt uppdatera utan att behöva göra en ny release av appen. Om någon av dessa förmågor är nödvändiga, rekommenderas att återanvända några av de andra Covidbevis projektens verifieringsappar som redan har dessa funktioner. Referensappen har byggd i Xamarin, vilket är ett .NET applikationsramverk som möjliggör en gemensam kodbas för flera plattformar (Android, IOS, Windows). Den har under en längre tid planerats att fasas ut och har i skrivande stund EOL satt till 1 maj 2024.

Revokera intyg

Funktion för att revokera intyg. En administratör ska ha möjlighet att återkalla ett intygs status. Processer för hur detta ska godkännas och verifieras ligger i konsumentförmågan. Tjänsten ska baserat på intygets ID skapa ett kondensat(hash) enligt beslutad revokeringsmetod som sedan läggs till intyget i spärrlistan i VDRen. Om giltighetstiden för intyget hålls nere, finns det ett mindre behov av denna tjänst.

Hantera PKI

Public Key infrastructure eller PKI är tekniska tjänster, rutiner och processer som krävs för att skapa tillit för intyget. Tillit säkerställs genom asymmetrisk kryptering, ett nyckelpar med en privat och en publik nyckel skapas och används för att skapa certifikat för att digitalt signera dokument. Utfärdartjänsten behöver detta certifikat (Document Signer Certificate - DSC) för att kunna utfärda ett intyg med en kryptografisk signerad datamängd i QR koden. Certifikatet skapas av en Certificate Authority enligt en tillitsmodell som specificeras för intyget. Det behöver också finnas en distribueringsnod för metadata såsom den publika nyckeln (VDR), som verifieringsappar och tjänster kan synka mot. Dessa tekniska förmågor samt rutinerna och processerna runt detta ingår i förmågan att Hantera PKI.

Certificate Authority (CA)

Under Covidbevis projektet sattes en dedikerad CA upp för ändamålet att utfärda dokumentcertifikat för att digitalt signera intygen i utfärdartjänsten. Det fanns EU specifikationer på hur certifikaten skulle utformas med giltighetstider, utökade fält och ansvarig utgivare som gjorde att det behövdes en dedikerad CA. Det finns inget tekniskt som hindrar från att använda samma CA tjänst till flera olika ändamål om tillitsmodellen tillåter. Som ett exempel har SDK sin specifika trustmodell att alla certifikat som ges ut av denna CA tillhör en accesspunkt och inget annat. Men rent hypotetiskt skulle man kunna ha en annan CA instans för TLS cert (kommunikation) och en annan för digitala signaturer av intygsdokument osv. Där varje CA instans har sin unika identitet och nyckel. Viktigt att tänka på hur spärrlistan är konfigurerad för CAn för intyg, eftersom även detta avgör hur länge ett intyg är giltigt i offline läge.

För att den privata nyckeln som används av CA tjänsten inte ska hamna i fel händer, hanteras den säkert i en HSM (Hardware Security Module). Processen runt hur detta kallas för nyckelceremoni och behöver tas fram av utfärdaren, som en del i PKI dokumentationen.

CA tjänsten som används inom Covidbevis är öppen källkod under Sweden Connect och det finns en ny ”headless CA” som kan användas för att spinna igång en CA tjänst i en ”hyllösning”. Man har gjort en logisk separation av CA Admin tjänsten för att ytterligare skydda CA delen (frontend/backend). Möjliggör även till CA funktioner via API, såsom att utfärda cert.

Om man utgår från de olika beredskapsnivåerna som finns beskrivna i checklistan, så kan det finnas scenarios där man vill flytta infrastrukturen mellan nivå 2 och 3. Då finns det fördelar med att ha en lokalt installerad CA istället för självsignerade certifikat. Det kan också vara en fördel att förfarandet ser nästan likadant ut oavsett beredskapsnivå. Det finns dock utmaningar med de hårdkodade URLerna som finns i certifikaten, som verifieringsapparna behöver synkas mot.

Nyckelceremoni

Eftersom projektet ser olika tänkbara beredskapsnivåer är denna fråga relevant för fortsatta arbete med exempelvis MSB. Det finns etablerade processer dokumenterade, både hos försäkringskassan och inom Sweden Connect (SUNET) för hantering i vanliga datahallen. Men exakt hur hela processen hanteras från generering av nyckelpar till certifikatutfärdande, samt vilka som ska bevittna nyckelceremonin är upp till varje enskild organisation att etablera.

Verifierbart dataregister - (VDR)

Distribueringsnod för publika nycklar, spärrlistor, regler mm. Begreppet VDR används främst inom W3C Verifiable Credentials standarden. Kallas för ”Trustpoint” inom Covidbevis. Det är denna nod som verifieringsappar synkar sin metadata ifrån.

”Trustpointen”/VDRen är specifikt framtagen för Covidbevis och används till att distribuera publika nycklar, regler till verifierare och till EU. Behöver bearbetas för att ta bort funktioner som är specifika för covidbevis, såsom synk mot EU, value sets. Initialt räcker det förmodligen med ett referensprojekt med ett API för att synka certifikat/nycklar och regler.

Hantera statistik

Tjänsten förutsätter att man lagrar/arkiverar intygsdata i en databas, så att konsumenter kan plocka ut statistik och ta rätt beslut. Erfarenheterna runt Covidbevis har visat hur viktigt det är att kunna ta ut statistik för uppföljning. I en samhällskritisk situation skulle det dessutom kunna vara underlag för viktiga datadrivna beslut, exempelvis att veta hur många som verifierats på en viss plats, hur folkmassor rör sig i samhället eller hur många intyg som begärts ut baserat på demografi och region. Något som helt saknas i Covidbevisfallet är info om intyg som verifierats, var verifieringen utfördes och vilket utfall kontrollen resulterade i. Då skulle man kunna fånga avvikande beteenden.

”Analysera tjänsten” i systemskissen, kan vara vilken generisk BI applikation som helst, exempelvis SAP BO, Qlikview. Syftet är att kunna visualisera den data som finns i statistik databasen och skapa/schedulera rapporter.

Statistiktjänst

Konsument på meddelandekön för att hantera statistik från intygstjänsterna samt hämtar aggregerad statistik från verifieringsappar genom VDRen. Utfärdandetjänsten lägger upp intygsdata på meddelandekön.

4.4 Ramverk för intygshantering

Syftet med ramverket är att hjälpa offentlig sektor med ett gemensamt språk och strategi runt intygshantering, idag och på sikt. Förslagsvis publiceras ramverket under Digg rekommenderar.

Ett förslag och utkast på ramverk för fortsatt arbete finns i Ramverk för intygshantering.

Ramverket kan innehålla

• Terminologi/Definitioner
• Lösningsdrivande krav
• Icke funktionella krav
• Trendspaning/omvärldsanalys
• Rekommendationer på tekniska lösningar, idag och på sikt Kontaktlös verifiering
• Strategier för offline verifiering
• Digital inkludering
• Referenskod
• Länkar och referenser till standarder och annat relevant arbete inom området
• Frågor och svar

4.5 Attributintyg - Ekosystem runt EU-plånboken

Projektet har i flera möten med specialister inom området sett ett behov av stödjande centrala tjänster och support i samband med utrullningen av ekosystemet inom offentlig sektor. Ekosystemet runt EU plånboken är dock ett pågående arbete tillsammans med de andra EU medlemsländerna och är i skrivande stund inte tekniskt moget för de krav som finns specificerade i nya eIDAS förordningen. Det gör att vi just nu endast kan spekulera i vilka förmågor som bör hanteras centralt.

4.5.1 Konsumentförmågor

Utfärda attributintyg

Skapa ett kondensat (hash) av intyget och skicka till en central tjänst för att generera och signera enligt önskat VC dataformat.

Ansluta utfärdartjänst till central tjänst för att ”Generera attributintyg”

Onboarding och auktorisation.

Ansluta e-tjänst till valideringstjänsten (attributintyg)

Onboarding och auktorisation.

Hantera återkallande av attributintyg

En utfärdare måste kunna revokera (återkalla) ett attributintyg om det visar sig att det utställts på felaktiga grunder eller på andra sätt förfalskats/förvanskats.

Hantera distribuering av metadata till Verifierbart Data Register (VDR)

DID dokument och annan metadata från utfärdare.

4.5.2 Centrala förmågor

Generera attributintyg

Central tjänst för att generera VC i olika format, som hjälper offentlig sektor att utfärda attributintyg i samma dataformat, så dom går att kombinera.

Hantera verifierbara dataregister

Hantera DLT/blockkedje noder som innehåller DID dokument, Revokering/spärrlista, schema för ekosystemet runt EU plånboken / Decentraliserad identitet.

Verifiera attributintyg offline

En verifieringsapp som synkar metadata från VDRen.

Verifiera attributintyg online

Ett API med en tjänst som verifierar signaturer och annan metadata mot VDRen.

Ackreditera nya utfärdare

Sverige kommer behöva ha en eller flera organisationer som ackrediterar nya utfärdare. Detta gör att dom får skrivrättigheter till DLTn.

Granska utfärdare

Som tillsynsmyndighet kommer det finnas behov att granska utfärdare, både inom offentlig och privat sektor.

Organisera forum för samverkan och support

Under utrullning av ekosystemet runt EU plånboken inom offentlig och privata sektorn kommer det behövas ett forum för samverkan och support.

Hantera katalogtjänst för utfärdare av attributintyg

Det kommer troligtvis behövas en katalogtjänst som listar och möjliggör sökning/indexering av utfärdare och attributintyg direkt i plånboken.

Hantera katalogtjänst för verifierbara dataregister

Det kommer troligtvis behövas en katalogtjänst för verifieringsappar att välja rätt VDR att synka metadata ifrån.