# Einführung von SARS-CoV-2 Schnelltest-Pässen als Beitrag zur diskriminierungsfreien und sicheren Öffnung der Deutschen Wirtschaft

Autoren: Dr. Carsten Stöcker, Dr. Michael Rüther, Dr. Susanne Guth-Orlowski
Version: 0.2
Status: Draft

## Abkürzungen

| Akronym | Beschreibung |
| --- | --- |
| CWA | Corona-Warn-App |
| eHBA | elektronischer Heilberufsausweis |
| GTIN | GS1 Global Trade Identification Number |
| HCP | Health Care Professional, medizinisches Fachpersonal |
| KYC | Authentifizierung, Know-Your-Customer, Feststellen der Identität eines Nutzers |
| sGTIN | serialized GTIN |
| TI | Telematik Infrastruktur der Gematik |

## Zusammenfassung

Mit der Einführung von elektronischen Impfnachweisen und Testpässen soll ein sicheres Öffnen von gesellschaftlichen und wirtschaftlichen Aktivitäten in Deutschland ermöglicht werden.

Derzeit wird an einer schnell zu implementierenden Lösung für den **Impfnachweis** gearbeitet. Diese Lösung soll über die Nutzung von Gematik TI und elektronische Heilberufsausweise (eHBA) eine Authentifizierung eines Arztes gegenüber einem Impfregister ermöglichen. In diesem Impfregister trägt der Arzt die Impfdaten zu einer Person ein. Das Impfregister erstellt dann ein Impfzertifikat. Dieses Zertifikat kann die geimpfte Person dann von einem Server abrufen und in einer Smartphone App (z.B. Corona Warn App) speichern. In einer späteren Phase soll diese zentrale Lösung zu einer Lösung mit dezentralen Komponenten weiter entwickelt werden (**Hybrid-Ansatz**).

Aus ethischen, gesellschaftlichen und wirtschaftlichen Gründen sind für nicht geimpften Personen Angebote anzubieten, mit denen Sie nachweisen können, dass sie zu einem gegebenen Zeitpunkt nicht COVID-infektiös sind. Damit soll eine **positive Diskriminierung von geimpften Personen** vermieden werden. Nicht geimpften Menschen wird mit einem solchen Angebot eine gleichberechtigte Teilnahme am gesellschaftlichen und wirtschaftlichen Leben ermöglicht.

Angebote für nicht geimpfte Personen erfordern die Einführung eines **sicheren, verifizierbaren Testpasses**, der weitgehend abgesichert ist gegen Fälschung. Bei der Einführung einer solchen Lösung ist ein Ausgleich zwischen den Zielsetzungen von Schnelligkeit, Skalierbarkeit, Sicherheit und Privatsphäre abzuwägen.

Dieser Beitrag beschreibt, wie eine flächendeckende Infrastruktur zur Ausstellung von **verifizierbaren Testpässen für einen Tag** (z.B. 24 Stunden) aufgebaut werden kann. Analog zum Impfnachweis soll eine Person über einen Testpass nachweisen, dass sie zum aktuellen Zeitpunkt nicht ansteckend ist. Damit kann dieser Person Zugang zu gesellschaftlichen und wirtschaftlichen Aktivitäten gewährt werden.

## Anwendungsfälle

Die folgende Tabelle gibt einen Überblick über die verschiedenen Anwendungsfälle für Impfnachweise und Testpässe.

| # | Impfung o. Test | Beschreibung | Durchführender Akteur | Retrofitting-Ansatz |
|---|---|---|---|---|
| 1 | Impfnachweise | Credential* als QR-Code über eine Impfung | **Impfzentren**, Hausärzte | **Anbindung von Systemen der Ärzte und Impfzentren**, die Credentials über Testergebnisse ausstellen. Diese Credentials können direkt von dem Patienten abgerufen werden. Trust Domain: Gematik TI oder CGM, Individuelle Anbindung der Impfzentren |
| 2 | Labortests | Credential* als QR-Code über PCR- oder Antikörper-Tests | **Testlabore** | **Anbindung von LIMS-Systemen**, die Credentials über Testergebnisse ausstellen. Diese Credentials können direkt von dem Patienten abgerufen werden. Trust-Domain: Laborkonzerne, LIMS-System Hersteller |
| 3.1 | HCP-Schnelltests | Credential* als QR-Code über Antigen-Schnelltests | **Schnelltest-Zentren**, Ärzte und Apotheker, Arbeitsmediziner in Unternehmen | **Anbindung von Systemen von Ärzten, Apothekern oder Schnelltestzentren** (auch Böblinger Modell), die Credentials über Testergebnisse ausstellen. Diese Credentials können direkt von dem Patienten abgerufen werden. Trust Domain: Gematik TI, Noventi oder individuelle Anbindung| |
| 3.2 | Schnelltests unter Aufsicht | Credential* als QR-Code über Antigen-Schnelltests | **Schnelltest-Kioske**, große Arbeitgeber, Einzelhandel (z.B. dm, Rossmann, Müller, ALDI) | Versorgung der **Schnelltestentitäten** mit der Fähigkeit Credentials auszustellen. Trust Domain: www.unternehmen.de als Trust Domain des Unternehmens |
| 3.3 | Laien-Selbsttests | Credential* als QR-Code über Antigen-Schnelltests | **Individuelle Personen** | Senden eines Fotos des **Selbsttestergebnisses** zusammen mit der sGTIN einer individuellen Testeinzelverpackung an einen Schnelltest-Credential-Server. Schnelltest-Credential-Server überprüft sowohl Foto als auch Authentizität des Testes und stellt dann ein Selbsttest-Credential aus. **Voraussetzung:** Serialisierung der Schnelltests |

Ein **Credential** ist ein elektronischer, mit **digitaler Signatur versehener Nachweis** in Form eines **Zertifikates** über das Ergebnis eines Corona-Tests. Es kann als QR-Code vorgezeigt werden. Dieser QR-Code kann von jedem beliebigen Akteur eines Ökosystems verifiziert werden, ohne dass dieser Akteur eine Vertrauensbeziehung zum Aussteller des Zertifikates haben muss.

"HCP-Schnelltests" (3.1) und "Schnelltests unter Aufsicht" (3.2) werden beide unter Beteiligung von mindestens einer weiteren den Testprozess betreuenden Personen durchgeführt. Die beiden Fälle unterscheiden sich im Wesentlichen darin, dass entweder medizinisches Fachpersonal oder Laien den Test unter Aufsicht durchführen. Beiden gemeinsam ist das Vier-Augenprinzip von zu testender Person und der aufsehenden Person. Die Umsetzung der Aufsicht kann verschiedene Ausprägungen haben:
1) Person und Testkit sind für die Zeit der Testdauer unter Aufsicht oder zumindest in örtlicher Nähe, bevor das Testpass-Zertifikat ausgestellt wird.
2) Person bekommt einen QR-Code mit einem Testidentifikator und gibt das Testkit ab. Nur das Testkit bleibt unter Aufsicht. Nach Ablauf von Wartezeit für den Test und Erfassung des Testergebnisses kann die Person über das Einscannen des Testidentifikators via QR-Code sich das Testzertifikat von einem Server abholen. Die Person wird nach dem Erhalt des Zertifikates durch die CWA über das Testergebnis informiert. Im Falle eines positiven Testergebnisses wird sie aufgefordert einen PCR-Test durchführen zu lassen.
3) Persönliche Daten der Person werden erfasst und verifiziert. Die Erfassung der persönlichen Daten kann vorab über eine Terminvereinbarungssoftware geschehen. Die Verarbeitung der persönlichen Daten ermöglicht eine zielgenauere Fallverfolgung. Sie stellt einen flächendeckenden Roll-out jedoch vor deutlich größere technische Herausforderungen und kann daher nicht einfach und schnell genug flächendeckend umgesetzt werden.

Nach unserer Einschätzung gibt es beim "Laien-Selbsttest" (3.3) aufgrund fehlender Voraussetzungen zu viele Manipulationsmöglichkeiten, um ein Testzertifikat auszustellen, das für Einlasskontrollen verwendet werden könnte. Auf diese Voraussetzungen wird weiter unten detaillierter eingegangen. Trotzdem sind Laien-Selbsttests sinnvoll und die Nutzer sollten aufgefordert werden, freiwillig das Testergebnis in die CWA einzugeben. Die CWA gibt dann Empfehlungen wie im Falle eines positiven Tests zu verfahren ist, fordert auf einen PCR-Test durchzuführen und informiert über ihr anonymes Kontaktverfolgungsverfahren potenziell gefährdete Nutzer.

Impfnachweise (1) und Labortests (2) werden derzeit in anderen Projekten behandelt. Spherity arbeitet in diesen Projekten zusammen mit Gematik, Compugroup Medical und Bundesdruckerei auch an einer **dezentralen Hybrid-Lösung** für Impfnachweise (SSI-Lösung). Details siehe [Gitlab Gematik](https://git.labor.gematik.de/cstoecker/scenario-documentation/-/blob/7f8c2c09689abaa2090dd2cd349212a41b098b82/COVID-19/sequence-diagram.asciidoc). Deswegen soll in diesem Artikel nur auf die **verschiedenen Formen von Schnelltests** eingegangen werden.

## Nutzen für Entscheidungsträger und Designprinzipien

Die in diesem Beitrag empfohlene Infrastruktur orientiert sich an den folgenden Nutzenpotentialen und Designprinzipien:

1. Diskriminierungsfreiheit
2. 4-Augenprinzip bei der Dokumentation von Schnelltests
3. Flächendeckender Roll-Out
4. Einfache Integration in den Alltag
5. Erhöhung der Sicherheit für Bürger und Unternehmen
6. Dezentraler Charakter der vorgeschlagenen Lösung
7. Hohes Maß an Anonymität
8. Compliance Check für Einzelhändler, Veranstalter, Gastronomen, Arbeitgeber und Verkehrsanbieter
9. Infrastruktur für die sektorenübergreifende Verifizierung der Zertifikate
10. Negatives Testergebnis kann nicht doppelt verwendet werden
11. Incentivierung Corona-Warn-App zu nutzen (nur mit CWA kann ich am öffentlichen Leben teilnehmen) und Entlastung der Gesundheitsämter durch bessere Kontaktverfolgung
12. Echtzeit Reporting aller bundesdeutschen Tests über CWA-Spherity Infrastruktur (Coronavirus SARS-CoV-2 – National Response Dashboard)
13. Analyseinstrumente zur Aufklärung der Dunkelziffer bei Corona-Infektionen sowie einer Erweiterung der RKI-Datenbasis zur Ermittlung der erreichten Herdenimmunität nach Landkreisen
14. Aufnahme von GAIA-X Architekturprinzipien (insb. dezentrales Identitäts-Framework)
15. Optionalität der technischen Infrastruktur für die verschiedenen Anwendungsfälle (Impfnachweise, Testpässe, SSI)

Wir gehen davon aus, dass aufgrund der vielen Vorteile der Infrastruktur eine **hohe Kampagnenfähigkeit** besteht. D.h. das alle von einer sicheren Öffnung profitierenden Unternehmen und Berufsgruppen einschließlich vieler Künstler mit einer hohen Kommunikationsreichweite, für die Nutzung dieser Infrastruktur werben werden. Damit kann bei geeigneter Planung ein sehr positives ich selbst verstärkendes Momentum für die Adoption der hier beschriebenen Lösung entstehen.

## Lösungsansätze und Restriktionen für Schnelltests

### 3.1 HCP-Schnelltests (personalisiert)

Aktuell sind im Landkreis Böblingen fünf Test-Center eingerichtet, bei dem jeder Einwohner zweimal wöchentlich zur Testung erscheinen kann.

Nutzer vereinbaren vorab einen Termin für die Testung. So können durchschnittliche Wartezeiten von vier Minuten realisiert werden. Die Terminvereinbarung hat den Vorteil, dass eine Personalisierung der Test-Zertifikate sehr effizient umgesetzt werden kann, da die personenbezogenen Daten über die Terminanfrage zur Verfügung gestellt werden können.

Jedes Center kann bis zu 100 Test/h vornehmen, die Kosten je Testung liegen in Summe bei 18EUR/Test. Bei einer positiven Testung wird im Anschluss ein PCR-Test vereinbart. Die Test-Center sind an Apotheken angebunden. Höchstsatz pro Abstrichstation pro Stunde war in Böblingen 120 Test/h.

Quelle: KOMMUNAL, LANDKREIS LEGT BLAUPAUSE VOR, [Böblinger Modell: Kann SO der Lockdown in wenigen Tagen beendet werden?](https://kommunal.de/boeblinger-modell-lockdown)

Technisch ist eine Zertifikate-Infrastruktur für Testpässe für den HCP-Schnelltest weitgehend identisch mit einer Infrastruktur für Schnelltests unter Aufsicht. Wichtigste Unterschiede sind, wer den Test durchführt und ob eine Integration mit einer Terminplanungssoftware stattfindet oder nicht. Im Rahmen eines Bundesweiten Roll-Outs ist eine solche Integration mit einem höheren Aufwand versehen, kann aber von Apotheken und Ärzten geleistet werden.

Die Beschreibung der Zertifikate-Infrastruktur für Testpässe wird in den folgenden Kapiteln vertieft.

### 3.2 Schnelltests unter Aufsicht (nicht personalisiert)

Im Gegensatz zu dem Böblinger Modell mit medizinischem Fachpersonal und Terminvereinbarungs-Software würden bei "Schnelltest unter Aufsicht" weder Terminvereinbarungen vorgenommen werden noch die Tests von medizinischem Fachpersonal durchgeführt. Damit wäre auch eine Personalisierung der Test-Zertifikate deutlich aufwendiger.

#### Vier-Augenprinzip und vertrauenswürdige Stellen

Schnelltests unter Aufsicht basieren auf dem **Vier-Augenprinzip**: Beteiligt sind der Nutzer und eine weitere Person einer vertrauenswürdigen Organisation wie z.B. Apotheke, Rotes Kreuz, Einzelhändler oder Arbeitgeber. Diese Art der Schnelltests ermöglichen eine flächendeckende, skalierbare Ausgabe von Testpässen. Entitäten, die Schnelltests unter Aufsicht ausstellen, müssen in die Lagen versetzt werden, Testpass-Zertifikate mit einem privaten Schlüssel zu signieren.

Im Zielzustand ist angedacht, dass vertrauenswürdige Stellen einen Schnelltest ausgeben und "unter ihrer Aufsicht" das Ergebnis in Form eines digital überprüfbaren Zertifikates dokumentieren können. Dieses Zertifikat kann auf den getesteten Nutzer übertragen werden. Mit diesem Zertifikat kann ein Nutzer für einen Tag nachzuweisen, dass er oder sie nicht infektiös ist.

Eine große Herausforderung ist, dass es in Deutschland keine Digital Identität von Unternehmen gibt. Deswegen muss ein einfacher und skalierbarer Weg gefunden werden, dass eine solche Identität ausgestellt, skaliert und von Akteuren in den unterschiedlichsten Wirtschaftssektoren überprüft werden kann.

Daher schlagen wir vor, dass in einer ersten Phase über einen Retrofitting-Ansatz große Unternehmen befähigt werden, Testzertifikate auszustellen. Diese Testzertifikate können unter existierende Trust Domains der Unternehmen gehängt werden. Um keine Flut von Trust-Domains zu erzeugen ist es vorteilhaft mit wenigen Trust Domains anzufangen. Dabei ist ein Vorgehen zu empfehlen, dass mit großen Unternehmen oder allgemeinnützigen Organisationen beginnt, die diese Corona-Tests stationär verkaufen oder abgeben Beispiele sind (ohne Apotheken, da diese unter 3.1 analog behandelt werden).
* Deutsches Rotes Kreuz
* Bundeswehr
* Feuerwehr
* Malteser
* dm
* Rossmann
* Müller
* ALDI
* Lidl

#### Tests unter Aufsicht per Videochat

Es ist vorstellbar, dass "Tests unter Aufsicht" auch digital per Videochat analog zu dem Video-Identverfahren gemacht werden. Der Prozessvorgang einschließlich QR-Codes entspricht dem der physischen Tests unter Aufsicht. Positiv ist, dass in einem solchen Szenario die Abstandsregeln optimal eingehalten werden. Allerdings kann nicht ausgeschlossen werden, dass während des Videochats das Testkit vertauscht und durch ein bereits verbrauchtes Testkit ersetzt wird. Erschwerend kommt hinzu, dass die Testkits nicht serialisiert sind (Analyse hierzu siehe unter Laientests). Deswegen empfehlen wir, mit Vorort-Tests zu arbeiten und parallel das Video-Chat-Szenario im Kontext von Serialisierung und Laientests weiter zu untersuchen.

### 3.3 Laien-Selbsttests

Bei den Schnelltests gehen wir davon aus, dass ein **verifizierbarer Laientest** aufgrund wesentlicher fehlender Voraussetzungen nicht umgesetzt werden kann.

Sollten Laien-Selbsttests als Nachweis für einen Zugang verwendet werden, müssen sehr grundlegende Missbrauchsmöglichkeiten ausgeschlossen werden:
* Instrumente zur Überprüfung der Authentizität eines Test-Kits
* Wiederholte Nutzung eines Test-Kits an verschiedenen Tagen
* Wiederholte Nutzung eines Test-Kits durch unterschiedliche Personen

Diese Missbrauchsmöglichkeiten können nur ausgeschlossen werden, wenn die einzelnen **Testkits serialisiert** sind. Serialisierung bedeutet, dass auf jedem einzelnen Testkit die folgenden Informationen in Form eines eindeutigen, maschinenlesbaren Codes ([GS1 2D Data Matrix](https://www.gs1-germany.de/gs1-standards/barcodesrfid/gs1-datamatrix/)) aufgedruckt sind: Hersteller (MAH), Haltbarkeitsdatum, Charge-Nummer, eindeutige Seriennummer.

Unter der Annahme, dass Schnelltests serialisiert sind, können Schnelltestzertifikate nach der folgenden Methode ausgestellt werden:
1. Nutzer scannt die 2D Data Matrix eines einzelnen Testkits
2. Nutzer für Schnelltest erstellt mit der Corona-Warn-App ein Foto des Testergebnisses
3. Optional: Im Fall eines positiven Ergebnisses übernimmt die Corona-Warn-App die Information von betroffenen Kontakten (das geht bereits ohne Serialisierung)
4. Im Fall eines negativen Ergebnisses sendet über die Corna-Warn-App ein Foto des Schnelltestergebnisses zusammen mit den Serialisieriungs Informationen der 2D Data Matrix an einen **Schnelltest-Zertifikate-Server**
5. Der Schnelltest-Zertifikate-Server überprüft das Ergebnis und registriert, dass für ein individuelles Testkit (sGTINs) ein Schnelltest durchgeführt wurde.
6. Der Schnelltest-Zertifikate-Server stellt dann dem Nutzer ein Schnelltestpass-Zertifikat aus.
7. Pro Test-Kit ist nur eine Anfrage zulässig. Wird eine Anfrage für denselben serialisierten Schnelltest mehrfach angefordert (z.B. an verschiedenen Tagen oder Orten), wird kein erneutes Zertifikat ausgestellt.

Der Prozess kann verfeinert werden, wenn ein Authentizitäts-Check des Testkits eingebaut wird. Dazu gibt es verschiedene technische Umsetzungsvarianten, die für spätere Phasen anzudenken sind.

## Technische Umsetzung des Schnelltestpasses (3.1 und 3.2)

### Annahmen für flächendeckenden Massen-Roll-Out (1 Mio. Testpässe pro Tag)

| # | Annahme | Beschreibung | Bewertung |
|---|---|---|---|
| 1 | Geltungsdauer | Testpass-Credentials gelten für die Dauer von wenigen Stunden (z.B. 24 Sunden) | Aufgrund der eingeschränkten Zeitdauer sind auch die Missbrauchsmöglichkeiten eingeschränkt. |
| 2 | Authentifizierung | Es wird keine Authentifizierung der Nutzer (KYC) der Corona-Warn-App durchgeführt. | Der Verzicht auf KYC hat praktische und datenschutzrechtliche Gründe. Testpassausstellung ist anonym und deutlich schneller, da keine personenbezogenen Daten erfasst und überprüft werden müssen. |
| 3 | Personalisierung | Auf eine Personalisierung der Testpass-Credentials wird verzichtet. | Für den Alltagsgebrauch müssen Testpass-Credentials schnell und einfach zu verifizieren sein. Daher wird auf eine Kombination der Authentifizierung eines Nutzers über einen Personalausweis bei einer Einlasskontrolle verzichtet. Damit werden die Prozesse bei der Ausstellung des Testpass-Credentials und deren Verifizierung beschleunigt.
| 4 | Anonymität | Anonyme Testpassausstellung | Aufgrund des Verzichts auf Authentifizierung und Personalisierung ist die Anonymität der Nutzer gewährleitet. |

### Personalisierung

Technisch stellt die Personalisierung der Testpass-Credentials kein Problem dar. Es ist denkbar verschiedene Optionen der Personalisierung in differenzierten Ansätzen umzusetzen:
1. **Schnelltests** unter Aufsicht werden nicht personalisiert. Diese Zertifikate könnten ausreichen, um Zutritt zu diversen Bereichen im gesellschaftlichen Alltag zu ermöglichen (z.B. Zutritt zu Einzelhandel, Restaurants, Kulturveranstaltungen, etc.).
2. **HCP-Schnelltests** werden personalisiert, um bspw. Flugreisen zu ermöglichen. Personalisierte Credentials erfordern dann das Vorzeigen eines Personalausweises als zusätzlichen Faktor zur Überprüfung der Identität einer Person.
3. Weiterentwicklung der Lösung zu einem vollständigen **SSI-Wallet** mit Identifier und Schlüssel der Bürger (digitalisierter Personalausweis). Ein solches Wallet würde auch sogenannte KYC-Zertifikate enthalten.

Die Personalisierung der Testpass-Zertifikate kann im Zusammenhang mit einer Terminplanungssoftware zur Vereinbarung der Testtermine deutlich effizienter in den Prozessen der Testcenter umgesetzt werden (siehe Böblinger Modell).

Aufgrund von Datenschutz und dem höheren Aufwand für eine flächendeckenden Roll-Out sowie bei der Verifikation gehen wir davon aus, dass die Testpass-Zertifikate für Tests unter Aufsicht nicht personalisiert sind. Wir empfehlen zusammen mit dem RKI eine Abwägung durchzuführen, wie hoch der epidemiologische Effekt aus Manipulationsversuchen mit nicht-personalisierten Credentials eingeschätzt wird. Zudem empfehlen wir, die Corona Task Forces der großen Deutschen Versicherer wie Allianz und MunichRe bei der Entwicklung von Hybrid-Risikomodellen bestehend aus Pandemie-Modellen, gesellschaftlichen wirtschaftlichen Modellen, einzubeziehen.

Mit einem vollständigen SSI-Wallet kann man eine weitgehend digitale Personalisierung erreichen. Es entstehen dann jedoch Herausforderungen bzgl. Praktikabilität, KYC-Prozessen, Datenschutz und Nutzerfreundlichkeit. SSI-Wallet Protokolle mit Verifiable Credentials und Verifiable Presentations erfordern zudem aufwendigere Protokollprozesse. Vorteile sind eine höhere Sicherheit der Daten und Resilienz gegenüber Manipulationsversuchen. Die Herausforderungen sind grundsätzlich lösbar, erfordern jedoch eine intensivere Vorbereitung und längere Umsetzungsphase.

Unter der Annahme, dass es noch keinen **digitalen Personalausweis** gibt, wird ein vollständiges SSI Wallet für viele Prozesse vermutlich weiterhin mit einem physischen Personalausweis kombiniert werden müssen. Die Integration der **digitalen Ausweis-App der Bundesdruckerei** ist auch denkbar und wird in dem IDunion-Projekt untersucht. Alternativ könnten Identitäts-Authentifizierungsanbieter KYC Credentials ausstellen. Allerdings ist der KYC Markt fragmentiert und die Prozesse nicht standardisiert.

### Applikations-Architektur

Eine mögliche Applikationsarchitektur zeigt das folgende Bild. Wesentlich ist zum einen die eindeutige Nachvollziehbarkeit, dass ein Test-Center wirklich ein Test-Center ist (Abbilden einer sogenannte Trust Domain) und zum anderen, dass ein Test-Zertifikat unabhängig verifiziert werden kann.

### Trust-Domain

Eine Trust-Domain beschreibt wie Benutzer eines Systems authentifiziert werden und wie das Vertrauen in die Akteure hergestellt wird. Für die Ausstellung des Testpasses schlagen wir zum Etablieren der Trust-Domain die [DID:web Methode](https://w3c-ccg.github.io/did-method-web/) vor, welche auf das bereits aufgebaute Vertrauen in Top-Level-Domains, z.B. https://www.drk.de/, und deren x.509 Zertifikate aufbaut. Zusätzlich wird auf staatlicher Ebene ein White-Listing dieser Trust-Domains hinterlegt. Als staatliche Stelle kann beispielsweise das Bundesgesundheitsministerium (BMG) oder die Gematik fungieren.

Aus der einzelnen Trust-Domain werden dann im Falle von Filialunternehmen für jede Filiale entsprechende eindeutige Filialidentitäten abgeleitet, die dann entsprechende Testpässe ausstellen und signieren können. Gleiches gilt dann für entsprechende Test-Center, die z.B. durch das DRK betrieben werden.

Jedes Test-Center benennt und autorisiert hierfür Mitarbeiter, welche die Schnelltests der Nutzer beaufsichtigen. Jeder elektronische Corona-Testpass wird in Form eines Credentials von einem autorisierten Mitarbeiter eines zertifizierten Test-Centers ausgestellt. Hierbei wird der Testpass mit dem privaten Schlüssel des zertifizierten Test-Centers signiert. Der Nutzer speichert nun den signierten Testpass in seiner Corona-Warn-App ab.

Ein positives Testergebnis kann er nutzen, um an Aktivitäten des öffentlichen Lebens teilzunehmen. Ein negatives Ergebnis kann er freiwillig nutzen, um seine Kontakte zu warnen.


### High-Level Prozess (3.2 Schnelltests unter Aufsicht)

#### Folgende Annahmen liegen dem Prozess zu Grunde:

| # | Annahmen |
|:---:|---|
| **1.** | **Prozess „Ausstellung von Zertifikaten“** |
| 1.1.| Über Deutschland verteilt werden qualifizierte Test-Center eingerichtet (z.B. DRK, Rossmann, Aldi Filialen)[^1]|
| 1.2.| Diese Stellen verkaufen bzw. geben entsprechende Schnelltests ab und bieten auch das Ausstellen eines Nachweises für einen negativen Test an (Gültigkeit 24h)|
|1.3.| Das Ausstellen erfolgt, wenn ein entsprechend negativer Test vorliegt durch das Personal der Test-Center.|
|1.4.| Die ausstellende Stelle hat einen entsprechenden Rechner bzw. Tablet zur Verfügung. Auf diesem wird ein zu scannender QR Code erzeugt.|
|1.5.| Scannen des Codes erfolgt durch getestete Person über CWA (entsprechendes Scan-Modul ist bereits in CWA integriert)|
|1.6.| Nach dem Scan wird der entsprechende Nachweis bzw. das Zertifikat in die CWA gespeichert.|
|**2.** | **Prozess „Verifizierung“** |
|2.1.| Es gibt ein Verifier-App (für Unternehmen) und ein Verifizierungsmodul in der CWA (für normale Nutzer). |
|2.2.| Wesentliche Funktion <br> - Scannen des Credentials aus der CWA über das negative Test-Ergebnis <br> - Verifizierung des Credentials <br> - Übersicht über gescannte Credentials <br> - Export Funktion zum Nachweis des Einlasses von nur negativ getesteten Personen |
[^1]: Auswahl der Detailhändler erfolgte zufällig.
#### Prozess-Darstellung

| # | Schritt |
|:---:|---|
|**1.** | **Aufsetzen qualifizierte Stellen (Szenario Aldi, Rossmann)** |
|1.1.| Aufsetzen Spherity Identity Issuance-Modul: Administrator oder Spherity setzt entsprechende Identitäten für Filialen über einen API Layer oder eine Web App auf.|
|1.2. |Vergabe Filial-Identität (über Spherity Issuance-Modul) <br> <br> Verankern der Identität je Test-Center über sog DID:WEB Methode auf die Web-Domäne des Unternehmens (Retrofitting des x.509 Zertifikates des Unternehmens) z.B. in Form von https://www.drk.de/.well-known/center2371/did.json. Ein Web-Administrator muss einmal das Zusammenspiel zwischen Web-Domain und Issuance-Modul konfigurieren. <br> <br> Zusätzlich wird Domäne noch in White-Listing des BMG oder der Gematik aufgenommen. <br> <br> Über JSON File wird auf ein "DID Dokument" referenziert. Im DID Dokument ist kryptografisches Schlüsselmaterial hinterlegt (Public Key der Identität), welches für die Verifikation von Signaturen benötigt wird.|
|1.3.| Anmelden bei Issuance-Modul an qualifiziertem Test-Center (Szenario DRK, Aldi, Rossman) <br> <br> Integration mit Active Directory von DRK, Aldi, Rossmann, d.h. Mitarbeiter kann sich mit seinen Organisations-Daten in Wallet einloggen (damit kann Nachweis erbracht werden, welche Person der Organisation welches Zertifikat ausgestellt hat). Alternativ zur AD-Integration kann ein individuelles Onboadring von ausstellenden Personen angedacht werden. <br><br> Nach Anmeldung hat der Mitarbeiter die Möglichkeit Zertifikate auszustellen. |
|**2.** | **Ausstellung Zertifikat, einfachster Fall der Ausstellung** |
|2.1. |Auswahl des Schnelltests über Drop Down oder Scan des Testes. |
|2.2. |Klick auf Button „Zertifikat über Test ausstellen“. Der Zertifikatsservice plausibilisiert die Daten und führt weitere Checks durch (z.B. Geolokation). Auf z.B. Tablet wird dann ein QR Code mit einem Token angezeigt mit dem einmalig das Verified Credential abgerufen werden kann (erneuter Scan des Tokens liefert kein Credential zurück). Es muss sichergestellt werden, dass Mitarbeiter nicht für sich selber Testzertifikate ausstellen können. |
|2.3. |Getestete Person scannt QR Code und verlässt das Testzentrum. So entstehen keine Wartezeiten. Zuhause fragt die geteste Person per Corona Warn App das Testergebnis ab und speichert das entsprechende Verifiable Credential in der Corona Warn App ab.|
|**3.** |**Verifizierung**|
|3.1.|Geteste Person zeigt QR Code mit Credential über negativen Schnelltest über Corona Warn App an.|
|3.2.|Kontrollierende Stelle scannt über mobiles Verifizierungsmodul Credential ein.|
|3.3.|Credential wird verifiziert, Überprüfung der Verankerung der DID:WEB Domäne im Whitelisting des BGM bzw. der Gematik und Verifizierung der Signatur der ausstellende Stelle (z.B. Rossmann Filiale).|

**Warte- und Standzeiten** können vermieden werden, wenn der Patient den QR-Code bekommt und den Teststreifen bei dem Testcenter hinterlässt. Das Testcenter-Personal erfasst das Ergebnis für einen gegebenen QR-Code und es wird ein Zertifikat ausgestellt. Der Nutzer kann über den QR-Code dann das Ergebnis nach einer Wartezeit von ca. einer Stunde abrufen. Allerdings besteht dann bei Tests unter Aufsicht im Szenario eines skalierten Roll-outs eine erhöhte Verwechslungsgefahr zwischen Teststreifen und Personen, sofern hier keine besondere Infrastruktur zur Verfügung gestellt wird.

#### Sequenzdiagramm - Schnelltest unter Aufsicht ohne Personalisierung

Daraus ergibt sich für den Prozess "Schnelltest unter Aufsicht ohne Personalisierung" das folgende Ablaufdiagramm:


Eine Manipulationsmöglichkeit ist einen Screenshot eines Zertifikates aus der CWA zu erstellen und an eine andere Person weiter zu geben. Diesem Angriffsvektor kann entweder durch ein sicheres Protokoll begegnet werden oder durch die Einführung eines sich zeitlich wechselnden Authenticator-Codes (Wechsel z.B. alle 20 Sekunden). Aus praktischen Gründen schlagen wir vor, mit einem sich zeitlich wechselnden Authenticator-Codes zu beginnen.

#### Attribute

Wir schlagen vor, dass ein Schnelltest Verified Credential die folgenden Attribute beinhaltet:
- Unique Identifier des Schnelltest-Zertifikates
- Datum und Uhrzeit der Ausstellung
- Datum und Uhrzeit der Gültigkeit
- Identität in Form einer DID des Test-Centers, optional: Name Mitarbeiter
- GTIN und Schnelltestprodukt (optional)
- Aussage über negatives oder positives Testergebnis
- Signatur des Zertifikates (ausgestellt mit private key der Test-Center-Identität)

Beispiel für ein Antigen-Test-Zertifikat:

{ 
  "@context": [
    "https://www.w3.org/2018/credentials/v1",
    "https://w3id.org/testcredentials/v1"
  ],
  "type": [
    "VerifiableCredential",
    "AntigenTestCertificate"
  ],
  "id": "urn:uvci:af5vshde843jf831j128fj",
  "name": "COVID-19 Antigen Test Certificate",
  "description": "COVID-19 Antigen Test Certificate",
  "issuanceDate": "2021-02-19T12:19:52Z",
  "expirationDate": "2021-02-20T12:19:52Z",
  "issuer": "did:web:www.drk.de:center123:did.json",
  "credentialSubject": {
    "type": "AntigenTestEvent",
    "testCentre": "DRK 123",
    "antibodyTest": {
      "type": "Antigen Test",
      "disease": "COVID-19",
      "productCode": "C09EF87",
      "medicinalProductName": "CLINITEST Rapid COVID-19 Antigen",
      "marketingAuthorizationHolder": "Siemens Healthineers"
    },
    "testResult": "negativ"
  },
  "proof": {
    "type": "Ed25519Signature2018",
    "created": "2021-02-18T23:00:15Z",
    "jws": "eyJhbGciOiJFZERTQSIsImI2NCI6ZmFsc2UsImNyaXQiOlsiYjY0Il19..vD_vXJCWdeGpN-qKHDIlzgGC0auRPcwp3O1sOI-gN8z3UD4pI0HO_77ob5KHhhU1ugLrrwrMsKv71mqHBn-dBg",
    "proofPurpose": "assertionMethod",
    "verificationMethod": "did:web:www.drk.de:center123:did.json#z6MkiY62766b1LJkExWMsM3QG4WtX7QpY823dxoYzr9qZvJ3"
  }
}

Das Beispiel wurde in Anlehnung an das [Vaccination Certificate Vocabulary](https://w3c-ccg.github.io/vaccination-vocab/) konzipiert. Nachfolgend wird der Größenunterschied des oben gezeigten Beispiels eines verifizierbaren Berechtigungsnachweises in JSON-LD und CBOR-LD kodiert dargestellt:

| Enconding Technologie | Größe in Byte |
| --- | --- |
| JSON-LD | ~1000 |
| CBOR-LD | ~400 |

Aufgrund der Größenlimitierung der Daten, die in einen QR-Code hineinpassen, ist es vorteilhaft, [CBOR](https://tools.ietf.org/html/rfc7049) als Serialisierungsinstrument für Zertifikat-Daten und Proofs zu verwenden.

Alternative kann auch ein JSON oder CBOR Format ohne Linked Data (@context) verwendet werden. Diese Datenformate sind kompakter. Kompaktere Datenformate haben weniger granulare QR Codes zur Folge, die bei einer Massenanwendung schneller und zuverlässiger eingescannt werden können. Die Vorteile in der Nutzung von Linked Data (LD) bestehen in einer standardisierten Datenrepräsentation.

Spherity wird diese technische Frage weiter untersuchen, um die QR Codes für eine Massenanweung zu optimieren.

## Echtzeit Reporting: Coronavirus SARS-CoV-2 – National Response Dashboard

Wir schlagen vor, Test- und Impfzertifikate über eine einheitliche Infrastruktur auszustellen. Mit dieser Infrastruktur können im Einklang mit der CWA für beide Anwendungsfälle sowohl dezentrale Architekturprinzipien umgesetzt als auch eine bundesweite Reporting-Infrastruktur aufgesetzt werden.

Ein **Coronavirus SARS-CoV-2 – National Response Dashboard** könnte den Fortschritt wie folgt visualisieren und mit Indikatoren über die erreichte Herdenimmunität verknüpfen (Status der Einfärbung der Landkreise ist zufällig gewählt).


Das Dashboard wird eine zusätzliches Drill-Down-Funktionalität erhalten, mit der weitere **Daten auf Landkreisebene** bereit gestellt werden können. Mit dieser Transparenz können Entscheidungsträger sehr zielgerichtet **auf die jeweilige Situation vor Ort maßgeschneiderte Impf- und Testkampagnen** durchführen. Zudem enthält die Datenbasis auch die Anzahl positiver Antigentests. Damit trägt sie zur **Aufklärung der Dunkelziffer** von Corona Infektionen bei.

Eine solche Infrastruktur wäre zudem eine hochwertige Erweiterung der RKI-Datenbasis zur **Ermittlung der erreichten Herdenimmunität nach Landkreisen**.

Daten, die für das Reporting verarbeitet werden, werden völlig anonymisiert sein, sodass hier keine personenbezogenen Daten verarbeitet werden. Aufgrund der Homogenität der Infrastruktur, hätten RKI, BMG und Bundeskanzleramt mit diesem Instrument auf Knopfdruck sehr gute Transparenz über die Fortschritte der Impfkampagne und Umfang von Antigentest. Mit dieser Reporting-Infrastruktur werden politische Entscheidungsträger und Behörden mit einer signifikant besseren Datenbasis für ihre Entscheidungen auf nationaler und lokaler Ebene versorgt.

## Haftung und Compliance Monitoring

Es ist davon auszugehen, dass Unternehmen und Veranstalter im Falle eines **Super Spreader Events** haftbar gemacht werden, wenn sie keine korrekten Einlasskontrollen durchgeführt haben.

Die Spherity Verifier-App wird daher mit einem Audit Log ausgestattet, sodass Unternehmen oder Veranstalter nachweisen können, dass sie regelkonform die Einlasskontrolle durchgeführt haben. Dieser Audit Log soll so implementiert werden, dass keine personenbezogenen Daten gespeichert werden.

## Europäische Perspective

### Anforderungen der EU-Kommission

EU-Kommissionspräsidentin Ursula von der Leyen will noch in diesem Monat (März 2021) einen Gesetzentwurf für einen "digitalen grünen Pass" für Corona-Geimpfte vorlegen. "Damit werde klar, wie der europäische Impfnachweis konkret aussehen solle."", sagte von der Leyen am Montag in einer Rede vor den CDU/CSU-Abgeordneten im Europaparlament.

"Wir wollen in den nächsten Monaten die technischen Voraussetzungen schaffen", bekräftigte von der Leyen nach entsprechenden Absprachen beim EU-Gipfel vorige Woche. Und sie fügte hinzu: "Damit der digitale grüne Pass aber ein Erfolg wird, brauchen wir die Unterstützung aller Mitgliedsstaaten. Auch wir in Deutschland müssen die Voraussetzungen dafür schaffen."

Der digitale europäische Impfpass soll nach den Vereinbarungen des EU-Gipfels binnen drei Monaten technisch vorbereitet werden. Ziel ist, dass Corona-Geimpfte fälschungssicher ihre Immunisierung nachweisen können. Das könnte über ein einheitlich lesbares Dokument mit QR-Code geschehen, das man auf Papier oder auf dem Smartphone bei sich tragen könnte, ähnlich wie ein Bahnticket. Dazu müssen die nationalen Systeme der 27 EU-Staaten vergleichbar ausgestaltet beziehungsweise verknüpft werden.

### Umsetzung mit COVID Impf- und Testpass-Credentialing

Aus der Anforderung der EU-Kommission resultiert der Bedarf nach einer EU-weiten, Sektoren-übergreifende Impf-/Testpass Lösung. Der hier weiter detaillierte Nutzen des Impf- und Testpass-Credentialings gilt natürlich auch auf nationaler Ebene.

Sollte ein klassischer Ansatz mit zentralen Datenbanken verschiedener Issuer von Impf- und Testpässen gewählt werden, entsteht aufgrund der Kombinatorik eine große Herausforderung für die Sicherheit und Verifizierbarkeit von Daten.

Mit Kombinatorik meinen wir die Vielzahl aller möglichen potentiellen Verbindungsmöglichkeiten (n x m) zwischen Verifiern (n) in den unterschiedlichsten Wirtschaftssektoren (und EU-Ländern) und Datenbanken der Issuer (m) und das daraus resultierende großes Spaghetti- und Look-up-Problem:
• „Wie finde ich die Service-Endpunkte der Datenbanken zum Verifizieren der Zertifikate“ oder
• „Wie konsolidiere ich die verschiedenen Datenbanken in eine Datenbank, ohne dass die Daten auf diesem Weg manipuliert wurden."
• „Wie stelle ich sicher, dass die Test-Zertifikate von einer vertrauenswürdigen Stelle ausgegeben wurden?"

Das Problem wird auf EU-Ebene nochmal um ein Vielfaches größer.

Abgesehen davon fehlen mit klassischen Technologien portable und interoperable Signaturen. Somit sind GxP, Attributability, Electronic Records/Electronic Signatures (ERES) - Code of Federal Regulations Title 21, E2E Verifiability und Auditability von Ausstellungs- und Verifizierungsevents (z.B. Einlassevents) nicht umsetzbar. Ohne diese Eigenschaften sind Manipulationsversuche sowie ein bei einem Super Spreader Events entstehendes Haftungsinferno nicht aufklärbar. Solche Vorfälle würden dann Vertrauen in die gesamte Infrastruktur signifikant beschädigen.

Mit dem hier gemeinsam erarbeiteten dezentralen Hybridansatz in Kombination von DID:web können sowohl Spaghetti als auch Look-up Problem für Impf- und Testpässe gelöst werden. Zudem werden elektronische Signaturen und W3C Standards genutzt, um Authentizität und Integrität der Zertifikatsdaten zu überprüfen. Mit ERES können die Standards aus regulierten Life Sciences Systemen so auf eine sektorübergreifende Systemlösung inkl. Audit-Trails überführt werden.

Mit dem Linked Data Ansatz, findet sich ein eleganter Weg die Credential-Semantik über alle Issuer und Verifier effizient zu standardisieren. Hier sind von W3C CCG und CCI schon sehr viele Vorarbeiten geleistet worden. Es ist auch bereits untersucht worden, wie Testpass-Credentials in einem verifizierbaren QR Code codiert werden können.

Zudem denken wir, dass es daher sehr vorteilhaft ist, eine sichere und schnelle Integration und Wartung der Issuer-Module und der Verifier-Module mit einfach integrierbaren APIs und ERES, standardisierter Semantik sowie einem leicht zu etablierenden Root-of-Trust umzusetzen ist.

Die aktuelle Deutsche Integration der PCR-Labortestlösung folgt dem klassischen Ansatz. Die PCR-Labortestlösung kann mit dem vorgeschlagenen Ansatz erweitert werden, sodass sie sich nahtlos in eine Ziellösung einfügen lässt.

## Addendum - Code zum Sequenzdiagramm

Benutztes Tool: http://www.plantuml.com/

@startuml
actor getestetePerson as P
actor Aufsicht as A #blue
participant “Issuer-Tennant” as I #orange
participant Einzelhandel_Verifier as E
participant “Verifier-Modul” as V #orange
participant BMG #white

autonumber
== Onboarding des Issuers ==
I -> I : Verankerung DID über DID:Web Methode
== Test ==
A -> P : Übergabe Testkit
P -> P : Durchführen Test unter Aufsicht
I -> I : Anzeige Access Token
I -> P : Scan des Access Token für Zertifikat

P -> P : Verlassen des Testzenrums und Warten auf Ergebnis
A -> A : Feststellen des Testergebnisses
A -> I : Log-in Issuer-Modul Wallet
I -> I : Erstellung Zertifikat und Ablage in DB

== Abfrage Testergebnis ==

P -> I : Anfrage Zertifikat/Ergebnis mit Access Token
I -> P : Übermittlung des Zertifikats
P -> P : Entschlüsseln und speichern Zertifikat in CWA
== Nachweis ==
P -> E : Vorzeigen des QR Codes mit Zertifikat
E -> V: Einscannen des QR Codes
V -> BMG: Prüfung der Issuer-Domain in Whitelist
V <- BMG: OK!
V -> I: Anfrage DID-Dokument von Domain
V <- I: Aushändigen des DID-D mit PubKey
V -> V: Überprüfen der Signatur
V -> E: Rückmeldung Zertifikatüberprüfung
E <-> P: Abgleich Authenticator-Code (z.B. 3-stellige Zahl)
E -> P : Gewährung Einlass
@enduml