Ultimate Non Infectious Verifier

SSI/W3C Prozessablauf
Arzt stellt Impf-Credentials aus / Patient akzeptiert und speichert sie in seiner Wallet
Patient präsentiert erfolgreich zwei Impf-Credentials einem Verifier

Inspiration

Covid19-Impfzertifikate sind der digitale Schlüssel für die Wiedereröffnung des öffentlichen Lebens. Es wäre "einfach", gäbe es einen internationalen Standard für medizinische Daten und ihren sicheren Transport, aber jedes Land auf der Welt verarbeitet medizinische Daten anders. Damit ein indischer Fluggast in Frankfurt dennoch mit seinem digitalen Impfnachweis durch die Sicherheitskontrolle kommt, empfiehlt ein Großteil der daran arbeitenden Konsortien (z.B. die Covid Credentials Initiative) den Einsatz von selbstsouveränen Identitäten (SSI), dezentralen Identifieren (DIDs) und schlüssel- / nicht personenbezogenen Credentials (W3C VCs). Die hierbei enstehenden semantischen Standards sind bereits als Draft im FHIR-Standard markiert.

Wir arbeiteten im Rahmen des Health Hack 2020 an einem Demonstrator, der genau dieses Prinzip implementiert und haben uns insbesondere auf die Verifier-Seite konzentriert, die nicht nur die kryptografische, sondern auch die semantische Richtigkeit eines Credentials überprüft.

What it does

Wir haben drei User-Facing Applikationen entwickelt, für einen "Arzt" (Provider / Issuer), den Patienten (Holder / eine Credential Wallet) und das Fluggate / den Barbesitzer (Verifier). Jede Applikation legt beim Start einen frischen lokalen Ethereum-Account an, der zur Erzeugung der DIDs jeder Rolle genutzt wird. Wir schreiben derzeit keinerlei Informationen auf die Blockchain, der hier verwendete (uPort) Identitäts-Registrar-Contract wir lediglich benötigt, um sicherzustellen, dass Schlüsselmaterial weiterhin aktuell ist.

Unsere Provider-App erstellt auf Basis des FHIR4/HL7 Immunization-Standards ein Dokument und veröffentlicht ein "CredentialOffer"-Dokument, das selbst keine detaillierten Informationen außer der DID des Arztes enthält. Ein Patient scannt dieses CredentialOffer. Sobald er es akzeptiert, sendet er über einen Rückkanal (servergebunden) seine Akzeptanzmitteilung an den Arzt. Jetzt erzeugt der Arzt mit dem soeben erhaltenen Identifier des Patienten das echte Credential und sendet es über den Rückkanal an den Patienten. Das geschieht zwei Mal (für zwei Impfungen) und der Arzt kann jeweils eine andere Person sein. Entscheidend ist nur, dass die in der Wallet des Patienten liegenden Credentials keinerlei personenbezogenen Daten enthalten, aber durch die DIDs des Arztes und des Patienten (Subject) gesichert sind. Wir verschlüsseln derzeit die Daten nicht.

Sobald der Patient zwei Immunization-Credentials in seiner Wallet hat, begibt er sich zum Verifier, der ihm einen PresentationRequest (QR-Code) darstellt. Der Patient scannt diesen Code und erfährt so die DID (nicht die Profildaten!) des Verifiers. Er verpackt beide geeigneten Credentials in eine Verifiable Presentation für den Verifiert und sendet sie über den Rückkanal an den Verifier. Dieser kann anhand der Signatur feststellen, dass tatächlich die Person, die ihm gegenübersteht, diejenige ist, die die diese Presentation ausgestellt hat und kann sie nun semantisch auf ihren Inhalt hin überprüfen, sofern sie mit dem FHIR4-Standard für Immunization-Dokumente umgehen kann.

Sofern alle Prüfungen positiv sind, kann der Verifier den Patienten als "geimpft" betrachten ohne irgend etwas über seine Person, seine Email-Adresse oder sein Haustier in Erfahrung gebracht zu haben.

How we built it

Wir nutzen die Standardbibliotheken (uPort) für die Verankerung und Auflösung von Ethr-Identitäten und eine Custom Blockchain (Ganache) auf unserem lokalen Rechner. Da wir (noch) keine Modifikationen auf der Chain selbst vornehmen, sollte dies auch auf dem Mainnet funktionieren. Die Applikationen sind als Monorepo angelegt und basieren alle auf Typescript/React mit Chakra UI als Frontend-Bibliothek. Die Übermittlung und Enkodierung aller Credentials geschieht mit did-jwt und did-jwt-vc.

Challenges we ran into

Die Enkodierung und die Spezifikation für DIDs / VCs sind sehr gut und leicht mit Bibliotheken umsetzbar. Dramatisch viel komplizierter ist die Vermittlung der Requests zwischen den Parteien, ohne irgendetwas in eine Datenbank zu schreiben. Da es (abgesehen vom primär kommerziell ausgerichteten Hyperledger Aries) keine wirklich gute Standardbibliothek für DIDComm-Messaging gibt, haben wir uns an die Implementierung von Jolocom gehalten, um unseren Case zu implementieren. Genau genommen möchte man für die Credential- und Key-Aufbewahrung ja keine Custom Wallet nutzen, sondern einen Standard. Wir haben mit Jolocom, Trinsic und LiSSI direkten Kontakt und tatsächlich könnte man diese Wallets nutzen, aber nur unter erheblich stärkerer Beschränkung der beteiligten DIDs auf das Indy-Protokoll / Sovrin.

Accomplishments that we're proud of

Während der Enkodierungscode innerhalb der letzten 3 Wochen entstand, haben wir die Applikationsseite in Rekordzeit umgesetzt.

What we learned

Obwohl der Standard auf maximale Interoperabilität ausgerichtet ist, setzt ihn niemand so um, dass er einfach schon für unseren Anwendungsfall völlig unabhängig von DID-Methode oder Vertrauensanker funktionieren würde.

What's next for Ultimate Non Infectious Verifier

Einsatz von DIDComm v2 kompatibler Rückkanalkommunikation
Implementierung eines Revocation Contracts (bzw Revocation Schemas auf Ceramic)
DAO zur Verankerung des "Root"-Trusts
Credential Registry zum Abrufen von Arzt / Impfzentrum / BMG / WHO-Credentials (Chain of Trust)
Umwandlung von mehreren Credentials zu einem FHIR-Bundle-Credential (zeitverzögerte Herausgabe der Credentials durch einen dritten Arzt, nachdem die Impfung stattgefunden hat)
Adaption auf Wallets wie LiSSI, Trinsic, Jolocom
Evaluation des Protokolls auf Ceramic / 3ID / IDX erlaubt komplett serverlose Kommunikation und sichere Datenaufbewahrung