Blockchain heißt, vom expliziten Vertrauen in einzelne Geschäftspartner zum impliziten Vertrauen in Mathematik überzugehen. Doch in privaten Netzwerken müssen sich die Teilnehmer auf die Identitäten aller anderen Akteure verlassen können.
Für den Betrieb von zugriffs- und zutrittsbeschränkten Blockchains (Private Permissioned Blockchains), die auch in diesem Projekt verwendet wurden, müssen die konsortial bekannten Identitäten (hier: Unternehmen) auch auf technischer Ebene abgebildet werden. Eine eindeutige Zuordnung und die Skalierung dieser Identitäten muss für eine weitere Verwendung betrachtet und optimiert werden. Es gibt konkret drei verschiedene Identitäten im System:
1. Die Netzwerk-Identität
Die Knoten im Blockchain-Netzwerk besitzen eine Identität, d.h. eine Zuordnung zu einem Konsortialpartner (hier: Unternehmen). Diese wird durch die Authentifizierung am Netzwerk via Private-/ Public-Key-Verfahren technisch umgesetzt. Die Verwaltung dieser und damit auch das Onboarding neuer Knoten muss zukünftig den Governance-Regeln des Konsortiums folgen. Konkret muss der Administrator des jeweiligen Knotens einen Befehl auf der Kommandozeile ausführen, indem er den Namen der (Block-)Chain sowie die physische Adresse (IP-Adresse) eines bereits laufenden Knotens angibt. Damit wird - bei nicht-öffentlichen Netzwerken - die eigene Adresse (Wallet) des Knotens erzeugt und ausgegeben. Diese muss wiederum vom Blockchain-Netzwerk akzeptiert werden. Konkret müssen genauso viele Bestätigungen (Endorsements) für die Freigabe der Netzwerk-Identität eingehen, wie im Admin-Quorum Entscheidungen angegeben sind. Im Pilotprojekt wurden die Netzwerk-Identitäten zur Vereinfachung mit einem 50% Quorum von zwei Admin-Knoten freigegeben, ergo ein Knoten kann [Objekt?] freigeben. Die technischen Berechtigungen an Streams, sowie administrativen Rechte werden über diese Netzwerk-Identität verwaltet - sie ist also zentral für die Konsistenz des Blockchain-Netzwerks!
2. Die Nutzer-Identität
Die wirklichen Akteure (LKW-Fahrer, Logistiker) müssen ebenfalls identifiziert werden. Das Erzeugen dieser Identitäten obliegt in jedem Falle dem jeweilig verantwortlichen Konsortialpartner (hier: Unternehmen). Eine unternehmensübergreifende Identitätsverwaltung, Authentifizierung und Autorisierung bringt wenig Mehrwert, da die jeweilige Entscheidung sowieso in der Hoheit des handelnden Unternehmens liegt.
Im Pilotprojekt haben wir Netzwerk-Identitäten statisch zu den jeweiligen Konsortial-Identitäten vergeben. Dies wäre im produktiven Einsatz natürlich undenkbar, jedoch hätte jedes andere Vorgehen im geschlossenen Rahmen des Testlaufs zu erheblichem Mehraufwand geführt. Es gab im Piloten zwei Rollen; den Logistiker an der Rampe und den LKW-Fahrer. Je nach Rolle bei der Anmeldung wurde man einem Lesepunkt (Readpoint GLN – Global Location Number) oder einem LKW (Kennzeichen) zugeordnet.
Normalerweise würden Unternehmen die Identitäten und Rollen der Mitarbeiter selbständig verwalten, und diese über eine mögliche Anbindung eines externen Identity-Providers mit der Blockchain-Lösung und ihrer Netzwerk-Identität nutzen. Einen Sonderfall stellen Fahrer vom Spotmarkt (Ad-Hoc verfügbare Dienstleister) dar. Deren Existenz und die damit verbundene Hürde wurde uns erst im Identitäts-Management-Workshop in Potsdam klar. Hier würde das jeweils beauftragende Unternehmen eine Identität ausstellen, die nur genau für diesen Vorgang berechtigt ist, damit einem Missbrauch vorgebeugt werden kann.
3. Die Konsortial-Identität
Die dynamische Verwaltung von unternehmensinternen Identitäten und deren Korrelation mit Konsortial-Identitäten auf der Blockchain ist komplex und nicht zwingend für den Pilotbetrieb erforderlich. Des Weiteren sollten sich durch den Testbetrieb und die Entscheidungen zur Datensichtbarkeit noch verschiedene Identitätsmanagement-Ansätze ergeben, sodass diese Entscheidung und Modellierung zunächst ausgeklammert und stattdessen statische Identitäten (auf Basis der jeweiligen GLN) für die einzelnen Akteure inkl. deren Zuordnung zu einem Konsortialpartner genutzt wurden.
Weitere Betrachtungen für die Zukunft
Um Identitäten in einer konsortialen Blockchain zukünftig effizient zu verwalten und zu skalieren, sollte man einige Dinge beachten:
• Eine Identität sollte möglichst nicht pro Person ausgestellt werden, um keine Probleme mit der DSGVO zu bekommen.
• Die Konsortiums-Identität ist ausschlaggebend, da die logische Klammer zwischen technischer Netzwerk-Identität und Nutzer-Identitäten [VERB FEHLT]. Sie bietet ein virtuelles Verrechnungskonto für ein Unternehmen (GLN).
• Die Zuordnung von Konsortiums-Identität zum realen Unternehmen ist Aufgabe des Onboardings ins Konsortium.
• Temporäre Identitäten sind wahrscheinlich eine Spezialität der Logistik-Prozesse, aber dringend nötig, um die Realität abzubilden.
Wir sind in dieser Betrachtung noch lange nicht auf komplexe Themen wie selbstverwaltete Identitäten (Self-Sovereign Identities, für natürliche Personen) eingegangen - doch das Thema ist auch so bereits komplex. Hier trifft die analoge Welt auf die digitale und der Übergang muss sowohl leicht als auch sicher gestaltet werden.
GS1 Germany
Kommentare
Keine Kommentare