Frank Polster
Voraussichtliche Lesedauer: 7 Minuten
Szenario: dezentrale Identitätslösung mit Blockchain-Technologie
Unser Distributed-Ledger-Technologies-Team hat kürzlich einen internen Blockchain-Disruption-Workshop durchgeführt. Unser Ziel war es, Use Cases und ein Big Picture zu entwickeln, das zeigt, wie die Technologie bei uns und beim Kunden Anwendung finden kann. Blockchain Disruption Workshop Eine unserer Produktideen ist eine dezentrale Lösung für eine Mitarbeiter-ID, über die Zertifizierungen ausgestellt werden. Das können zum Beispiel…
Unser Distributed-Ledger-Technologies-Team hat kürzlich einen internen Blockchain-Disruption-Workshop durchgeführt. Unser Ziel war es, Use Cases und ein Big Picture zu entwickeln, das zeigt, wie die Technologie bei uns und beim Kunden Anwendung finden kann.
Blockchain Disruption Workshop
Eine unserer Produktideen ist eine dezentrale Lösung für eine Mitarbeiter-ID, über die Zertifizierungen ausgestellt werden. Das können zum Beispiel Ausbildungsnachweise und Projekterfahrungen sein. Diese Zertifizierungen können genutzt werden, um sich intern auf Projekte zu bewerben. Der Auftraggeber bzw. die Auftraggeberin auf Kunden-Seite kann entsprechende Zertifizierungen und Erfahrungen anschließend automatisiert prüfen und zum Beispiel einen Gesamtscore errechnen.
In diesen Gesamtscore kann zum Beispiel einfließen, ob der/die potenzielle Mitarbeiter/in schon für den Kunden gearbeitet hat, und wenn ja, wie oft oder wann zuletzt. Oder es kann geprüft werden, ob bestimmte, für den Auftrag benötigte, überprüfbare Qualifikationen vorgelegt werden können.
Der bzw. die Auftraggeber/in bekommt so einen besonders guten “Fit” von Bewerber/innen mit der für das Projekt gesuchten Expertise.
F&E-Projekt “digitale Identität”
Auf Basis der Ergebnisse des Workshops haben wir losgelegt und zunächst Anforderungen erhoben. Hierbei konnten wir uns auf zwei wesentliche Anforderungen festlegen:
- Einhaltung des Datenschutzes:
Die konzipierte Lösung muss alle geltenden Regeln zum Datenschutz einhalten. - Kompatibilität:
Wir wollen uns zum aktuellen Zeitpunkt nicht auf eine Blockchain-Plattform festlegen. Die Lösung soll also mit allen Blockchain Plattformen funktionieren.
Zusätzlich definierten wir ein Szenario, bei dem sich Mitarbeiter/innen von MaibornWolff auf Projekte von Kunden bewerben. Der Mitarbeitende meldet sich über unserer Weiterbildungsportal Aline für Schulungen an. Referent/innen bestätigen die Teilnahme. Aline attestiert nun dem Mitarbeiter / der Mitarbeiterin die Teilnahme. Diese Referenz wird anschließend bei der Bewerbung für ein Projekt weitergegeben. Abschließend hat der Kunde die Möglichkeit, die Referenz in einer Client-Anwendung zu prüfen.
Hierbei sollen drei Dinge geprüft werden:
- Gültigkeit des Zertifikats:
Jedes Zertifikat erhält ein Ablaufdatum. Das ist üblich, so ist beispielsweise das Cisco CCNA Zertifikat für drei Jahre gültig. - Aussteller des Zertifikats:
Dabei wird überprüft, ob der aus der Signatur extrahierte Public Key dem Aussteller des Zertifikats gehört. Das bedeutet, dass das Zertifikat wirklich vom Aussteller unterschrieben wurde und nicht von jemand Anderem. - Aussteller-Organisation: Um zu prüfen, ob der Aussteller überhaupt qualifiziert war, das entsprechende Zertifikat auszustellen, prüfen wir, ob der Aussteller einem Campus Netzwerk (z. B. TÜV) angehört.
Bei unserer Recherche stießen wir auf die kürzlich vorgestellten Standards für Decentralized Identifier und Verifiable Claims des W3C (World Wide Web Consortium – die, die auch das Internet gebaut haben). Das W3C genießt im Internet eine hohe Glaubwürdigkeit und Durchsetzungskraft, da aus diesem Consortium diverse Standards wie HTML hervorgingen. Wir versprechen uns eine hohe Wahrscheinlichkeit, dass diese Standards auch von anderen Lösungen verwendet werden. Das W3C stellt den Standard in diesem Blog vor.
Darüber hinaus genügt der Standard genau unseren Anforderungen: Er lässt sich auf jede Blockchain-Plattform anwenden. Und er hält aktuelle Datenschutzverordnungen ein, da die Daten der Identität nicht auf der Blockchain selbst, sondern bei der Person bzw. der Maschine gespeichert werden.
Weiter zeigte die Recherche, dass bereits heute verschiedene Projekte diesen Standard angenommen und implementiert haben, etwa diese:
- uPort – eine Self-Sovereign-Identity-Lösung für Ethereum,
- Sovrin – eine auf Hyperledger basierende Public Blockchain für Identity-Management,
- 3box – eine Identity- und Dropbox-Lösung basierend auf IPFS.
Anschließend wurde evaluiert, inwiefern sich die einzelnen Projekte eignen, um unser Vorhaben umzusetzen. Dabei zeigte sich, dass 3box und Sovrin noch in einer sehr frühen Phase stecken und aus unserer Sicht noch nicht reif für den Produktiv-Einsatz sind. Im Gegensatz dazu bietet uPort, ein Vorgänger von 3box, eine Lösung, die bereits in der Schweiz im Kanton Zug produktiv eingesetzt wird (hier gehts zur Meldung der Stadtverwaltung). Daher entschieden wir uns zunächst für diese Lösung und haben in einem folgenden Projekt evaluiert, inwiefern 3box eingebunden werden kann.
Architektur-Big-Picture
Aus den gewonnenen Erkenntnissen haben wir folgende Architektur abgeleitet:
Unser Konzept baut auf unserer internen Weiterbildungsanwendung Aline auf, das Zertifikate für absolvierte Weiterbildungen ausstellt. Die Zertifikate werden dem Mitarbeiter / der Mitarbeiterin ausgehändigt; diese/r kann seine Zertifikate über die interne Anwendung “Beraterprofil” (damit erstellen wir die Dokumente, mit denen wir unsere Expert/innen beim Kunden vorstellen) einem Profil zuordnen, welches dem Kunden digital oder analog übergeben wird.
Nach erfolgreicher Schulungsteilnahme trägt der Mitarbeiter / die Mitarbeiterin dies im eigenen Beraterprofil ein und kann optional das erhaltene Zertifikat hinterlegen.
Der Kunde / die Kundin kann die interne Anwendung “Zertifikatsprüfung” anschließend über Links, zum Beispiel aus dem Beraterprofil, starten und das Zertifikat einlesen. Es wird daraufhin geprüft.
Fazit
Der Prototyp zeigt sehr gut die Vorteile einer dezentralen Lösung im Umgang mit einer Digitalen Identität gegenüber einer klassischen IT-Lösung. Mit einfachen Mitteln lassen sich verifizierte Informationen schnell anwendungsübergreifend und nachvollziehbar einsetzen. Auf den Einsatz einer zentralen PKI kann verzichtet werden, wodurch Kosten für Wartung und Betrieb eingespart werden können.
Aus Sicht der Anwendung zeigt sich hier ebenso der Vorteil einer Plattformökonomie. Schulungsanbieter können ihre Angebote und Zertifikate auf dieser Plattform gemeinsam verwalten. Je mehr Anbieter diese Plattform nutzen, desto mehr weiterführende Dienste sind denkbar. Aber auch die einseitige Nutzung einzelner Schulungsanbieter auf einer gemeinsamen Blockchain ist denkbar. Die DLT ermöglicht es, dass alle auf einem gemeinsamen Datensatz und einer gemeinsamen Prozessimplementierung aufsetzen können. Die Nutzung der Zertifikatsprüfungsanwendung als IPFS-Anwendung sorgt zusätzlich dafür, dass Empfänger von Zertifikaten diese ohne die Installation einer zusätzlichen Anwendung schnell und einfach prüfen können – und das lokal!