Self-Sovereign Identity (SSI) : Identity- & Access-Management mithilfe von BlockchainVerfahren

Von André Kudra, Langen

Mit Beginn des Hypes wurden „die Blockchain“ und später allgemein Distributed-Ledger-Technologies (DLT) häufig als universelle Heilsbringer in allen IT-gestützten Anwendungsfällen dargestellt – nur selten konnten sie diesen Erwartungen gerecht werden. Für spezifische Bereiche wie das Identitätsmanagement war durch Dezentralisierung und Flexibilisierung mit Blockchains und DLTs jedoch schon früh Potenzial ersichtlich.

In der <kes>-Ausgabe zur it-sa 2016 analysierte der Autor im Artikel „Identity & Access mit der Blockchain“ [1], ob das blockchainbasierte Identity- und Access-Management (IAM) nicht nur vielversprechend, sondern eine große Sache ist: „Sicherlich bedarf es noch etwas Geduld, bis es so weit ist und die richtigen wertschöpfenden Anwendungsszenarien für die Blockchain herausgearbeitet werden – IAM auf der Basis eines Permissioned Distributed Ledgers könnte ein solches sein“, lautete damals die Schlussfolgerung. Die 2017 folgende Diskussion zur technischen Umsetzbarkeit einer blockchainbasierten digitalen Identität durch Autor und Team in einem weiteren <kes>-Artikel [2] zeigte Möglichkeiten und Limitationen bestehender technischer Komponenten auf.

In der Zwischenzeit wurde ein großer Teil des Potenzials bereits erschlossen: Der Begriff Self-Sovereign Identity (SSI) wurde global geprägt, technische SSI-Komponenten durch intensives Community-Engagement entwickelt, getestet und ausgefeilt. Bei SSI steht der Nutzer der digitalen Identität im Mittelpunkt, denn er selbst ist im Besitz seiner persönlichen Daten und entscheidet über den Fremdzugriff.

„Bring Your Own Identity“ (BYOI) bezeichnet hierbei die Idee und das Ziel, diese eigene Identität bei Bedarf in einem beliebigen Umfeld nutzen zu können – sei es privat oder geschäftlich, zum Online-Shopping oder in behördlichem Kontext (vgl. Abb. 1). Bestehende Konzepte wie Public-Key-Infrastructures (PKI) werden dabei nicht verworfen, sondern den sich abzeichnenden Herausforderungen angepasst und im Sinne einer Decentralized PKI (DPKI) weiterentwickelt. Der Dreiklang Aussteller–Inhaber–Verifizierer für SSI-Zertifikate (sog. Credentials, vgl. Abb. 2) ermöglicht eine effiziente und flexible Digitalisierung in verschiedensten Anwendungsfeldern.

Praxisorientierte SSI-Standardisierung

Ein sich herauskristallisierender Standard für SSI, der über eine Arbeitsgruppe des World Wide Web Consortium (W3C) formuliert wurde (www.w3.org/2019/did-wg/), sind die sogenannten Decentralized Identifiers (DIDs): Dieser Standard [3] wird für eine plattformunabhängige Umsetzung digitaler Identitäten benötigt.

DIDs sind ein neuartiger Typ von Identifikator für verifizierbare digitale Identitäten und stehen vollständig unter der Kontrolle des Eigentümers der Identität. Sie sind unabhängig von einer zentralisierten Registrierungs-/Zertifizierungsstelle oder einem Identity-Provider – man kann diese DIDs als eine Form der Identifizierung für selbstverwaltete digitale Identität ansehen. Um die Privatsphäre weiter zu erhöhen und eine Korrelation von Daten zu vermeiden, besteht eine digitale Identität aus sehr vielen DIDs. Es bedarf somit keiner „höheren“ Instanz, die einen DID erst generieren und daraufhin einem Benutzer zuweisen muss.

Mit DIDs existiert ein interoperables System, das ähnlich den Uniform Resource-Locators (URLs) im Internet agiert und eine Identitätsschnittstelle im Web bildet – mit dem Ziel, zentrale Punkte zu eliminieren und kritische zentrale Infrastruktur abzuschaffen. Eine DID-basierte Architektur fokussiert darauf, die minimale Menge von Attributen zu teilen, die für eine sichere Kommunikation zwischen zwei Parteien notwendig ist.

Die dynamische Realisierung von Zertifikaten, die mit flexiblen Inhalten bestückt in verschiedensten Szenarien einsatzfähig sind, erfolgt über sogenannte Verifiable Claims – ein Konzept, das ebenfalls durch eine W3C-Arbeitsgruppe erstellt wurde (www.w3.org/2017/vc/WG/). Ein Verifiable Claim ist eine Qualifizierung, Errungenschaft oder Information über den Hintergrund einer Entität, beispielsweise deren Name, Adresse, Bankverbindung, Schul- oder Universitätsabschluss. Ein solcher Claim beschreibt Qualität und Eigenschaften dieser Entität, die deren Existenz und Einzigartigkeit etablieren. Ein Set von Verifiable Claims wird als Verifiable Credential bezeichnet, ein Set von Credentials aggregiert sich zu einem Profil.

Hyperledger-Projekte

Die tatsächliche praktische (technische) Realisierung der Quasi-Standards erfolgt über kollaborative Initiativen – allem voran der von der Linux Foundation (www.linuxfoundation.org) getragene Hyperledger-Verbund (www.hyperledger.org), der zahlreiche prominente Mitglieder hat. Es vereinigt Unternehmensgrößen wie IBM, Intel, Bosch, SAP, accenture, American Express, Airbus, Daimler, Baidu, Fujitsu und Hitachi. Hyperledger ist eine Open-Source-Kooperation, um branchenübergreifend Blockchain-Technologie voranzutreiben.

Im Identitätskontext sind zwei Hyperledger-Projekte besonders hervorzuheben: Hyperledger Indy schafft ein speziell für dezentralisiertes Identitätsmanagement vorgesehenes Distributed Ledger (www.hyperledger.org/projects/hyperledger-indy), das Werkzeuge, Bibliotheken und wiederverwendbare Komponenten für die Erzeugung und Anwendung von unabhängigen digitalen Identitäten umfasst, die in interoperablen Blockchains oder anderen Distributed Ledgers verankert sind. Besondere Beachtung finden dabei Aspekte wie Performanz, Skalierbarkeit, Vertrauensmodelle und Privatsphäre. Hyperledger Aries fungiert hingegen als technischer Baukasten für das Erstellen, Übertragen und Speichern von Verifiable Credentials (www.hyperledger.org/projects/aries) – es stellt die Infrastruktur für blockchainbasierte Peer-to-Peer-Interaktionen dar.

Eine konkrete, praktische und aktuell bereits öffentlich verfügbare Implementierung von Hyperledger Indy ist Sovrin (https://sovrin.org, siehe auch [6]). Die Sovrin Foundation, eine Non-Profit-Organisation, hat gemäß ihrem Leitmotiv „Identity for All“ als ihre Aufgabe definiert, die Modelle der Self-Sovereign Identity und des dezentralisierten Vertrauens für jedermann frei zugänglich und verfügbar zu machen; Anwender erhalten freien Zugang zu einer digitalen Identität im Sinne eines öffentlichen Versorgungsguts. Die Betreiber eines schreibenden Nodes (sog. Stewards) werden durch das entsprechende Governance-Board der Foundation genehmigt. Dieser transparente Prozess umfasst eine Verpflichtung auf das gemeinsame Governance-Framework und stellt eine globale Diversität der beteiligten Organisationen sicher. Das Sovrin Network setzt auf einen sogenannten Public-Permissioned Ledger: Zum Einsatz kommt ein schneller und energiesparender Konsensmechanismus namens Redundant Byzantine Fault Tolerance (RBFT, [4]). Als globales Identitätsnetzwerk nutzt Sovrin DIDs, die eine Interoperabilität mit anderen Identitätssystemen gewährleisten.

esatus-interner Produktiv-Rollout

In den meisten Organisationen schließen Berechtigungskonzepte Workflows für Zugriffsanfragen und Bestätigungen ein, die auf Organisationsstrukturen basieren. Von diesen ausgehend lassen sich verschiedene Abstraktionen für Zugriffsentscheidungen ableiten (Zugriff für eine Person zu System, Systemfunktionen oder -daten ist möglich oder nicht), beispielsweise aufgrund der Anstellung bei einem Unternehmen, der Zugehörigkeit zu einer bestimmten Abteilung oder einem bestimmten Projekt sowie Kombinationen dieser Kriterien.

Auch im Fall der esatus AG ist das SSI-Berechtigungskonzept auf die Organisationsstruktur des Unternehmens zugeschnitten, was dank SSI mit wenig Aufwand implementierbar ist. Eine Zugriffsentscheidung kann allein auf der Zugehörigkeit zur Organisation begründet sein: Alle, die nachweislich für die esatus AG arbeiten, erhalten etwa Zugriff auf das Wiki im Intranet. Um dies in einem SSI-Berechtigungskonzept zu verwirklichen, muss man die Organisationsstruktur mit Schemata modellieren, die relevante Attribute für Zugriffsentscheidungen enthalten. Schemata sind erforderlich, um Credential-Definitionen zu erzeugen, die wiederum zum Ausstellen von Credentials verwendet werden können – der Nutzer speichert sie in seinem Wallet.

Bei der esatus AG wurde die esatus Wallet App, mit der alle SSI-Interaktionen abgewickelt werden, auf den Smartphones aller Mitarbeiter installiert. Als erster Use-Case wurde das auf „Atlassian Confluence“ aufgebaute interne Wiki mithilfe des Plugins „re:solution“ via Security-Assertion-Markup-Language (SAML) an die eigene SSI-IAM-Lösung SeLF angebunden. Mit der Wallet-App können Mitarbeiter einen QR-Code auf der Login-Seite scannen und erhalten dadurch Zugang zum Wiki. Das Berechtigungskonzept für SeLF an sich basiert vollständig auf SSI-Credentials, ist also „SSI-native“ und kommt ohne „klassische“ Zugriffskontrollmechanismen dazwischen aus.

Einschlägigen Best Practices folgend wurden im Projekt generelle Compliance-Policies umgesetzt:

• Vorstandsmitglieder (CEO und CIO) können jegliche Credentials ausstellen, einschließlich solcher für Abteilungsleiter und C-Level-Positionen
• Angehörige der Personalabteilung können Credentials für Beschäftigung, Abteilungszugehörigkeit (außer Abteilungsleiter und C-Level), persönliche Daten und postalische Anschriften ausstellen
• Abteilungsleiter können jegliche Projektzugehörigkeits-Credentials ausstellen
• Angehörige der IT-Infrastruktur-Abteilung können Regeln für ihre Anwendungen implementieren und ändern
• Credentials können nur für andere ausgestellt werden, nicht für sich selbst
• Credentials können nur für niedrigere Hierarchiestufen ausgestellt werden (bspw. kann der Personalabteilungsleiter keine Leiter-Credentials ausstellen – das ist dem Vorstand vorbehalten)
• alle Credentials werden nach einem Jahr ungültig, privilegierte nach sechs Monaten – danach müssen die Verantwortlichen sie neu ausstellen

Im Zuge des Rollouts wurden die grundsätzliche Motivation zur Anwendung von SSI im eigenen Unternehmen, die Berechtigungskonzeptmodellierung auf Basis der Organisationsstruktur, die Ableitung von Schema- und Credential-Definitionen, Compliance-Überlegungen, der Aufbau regelbasierter Berechtigungen mit Credential-based Access-Control (CrBAC), die praktische SSI-Anwendung sowie Rollout-Erfahrungen dokumentiert und in einem Whitepaper zusammengefasst [5]. Das SSI-Enablement des Wiki war allerdings nur der erste Schritt, die Anbindung weiterer interner Anwendungen ist in Planung.

Enterprise-IAM mit SSI

Häufig fokussiert sich die Diskussion um SSI auf die Vorzüge für den Nutzer: Zurückgewinnung der Datenhoheit, Sicherstellen der Privatsphäre, das Recht auf Selbstbestimmung – dies ist alles erstrebenswert und weiterhin gültig. Für Unternehmen besteht jedoch eine gleichermassen schwergewichtige Chance, das IAM auf die nächste, zukunftssichere Ebene zu heben: SSI bietet gegenüber anderen IAM-Methoden wesentliche Vorteile.

Derzeitige Lösungen wie Single-Sign-on (SSO) sowie die Möglichkeit, unterschiedliche Zugangsdaten und besonders lange und wechselnde Passwörter zu eliminieren, ist mit SSI leicht zu realisieren – das Potenzial von SSI geht aber noch weit darüber hinaus:

• Schnelligkeit: SSI-aktivierte Applikationen sind sofort für den Anwender verfügbar. Das benötigte IAM-Ökosystem wird signifikant vereinfacht, fehlerbehaftete und zeitraubende Synchronisierungen entfallen. Das Unternehmen stattet den Mitarbeiter einfach und unkompliziert mit entsprechenden Credentials aus, um den unmittelbaren Zugang zu gewähren. Die Attribute in den Credentials kommen direkt aus den Datenquellen, in denen sie originär entstehen („Golden Source“ / „Authoritative Source“). Eine direkte Kommunikation relevanter Komponenten ermöglicht es, den administrativen Aufwand auf ein Minimum zu reduzieren. Genauso schnell wie die Vergabe geht das Entziehen von Berechtigungen: Reaktionszeiten sind minimal und Berechtigungen bestehen dann und nur so lange, wie sie benötigt werden oder gerechtfertigt sind.
• Flexibilität: SSI hat eine PKI-ähnliche Funktionsweise und ein der klassischen PKI überlegenes Sicherheitsniveau. Mit dynamisch generierbaren Zertifikatsschemata – bei SSI Credential Definition genannt – und der expliziten Möglichkeit, jeden im dezentralisierten Netzwerk zum Aussteller zu machen (im Gegensatz zu PKIs, wo dies nur zentrale Certificate-Authorities können), entsteht bisher ungekannte Flexibilität. Credentials können nach Bedarf erstellt, zugeteilt und wieder entzogen werden – und zwar für jeden, unabhängig von der Organisationszugehörigkeit. Mitarbeiter können die ihnen ausgestellten Credentials anwendungs-, betriebssilo- und sogar unternehmensübergreifend nutzen. Vereinbarung, Design und Implementierung individueller Schnittstellen (APIs) zwischen Systemen und gegebenenfalls auch zwischen unterschiedlichen Organisationen sind obsolet. Ein Unternehmen kann allen (oder ausgewählten) Mitarbeitern eines neuen Dienstleisters Zugriff auf definierte Bereiche des Intranets gewähren, ohne sie in eigene Verzeichnisdienste aufnehmen oder in den Applikationen Benutzerkonten für sie anlegen zu müssen.
• Sicherheit: Derzeit sind Authentifizierungs- und Autorisierungsprozesse aufwendig und beruhen auf der Annahme, dass der eingeloggte Anwender tatsächlich der Eigentümer der Logindaten ist – eine nicht zu vernachlässigende Unsicherheit verbleibt. Mit Zwei-Faktor- (2FA) oder Multi-Faktor-Authentifizierung (MFA) strebt man an, die Sicherheit zu erhöhen. SSI-Credentials werden ausschließlich der berechtigten Person zugeteilt und in deren Wallet gespeichert: Nur der Anwender als Eigentümer der Credentials kann diese auch verwenden, um Proofs auf sie zu erstellen. Bei einer Kompromittierung des Wallets oder eines Geräts kann der Anwender die Verwendung seiner Credentials unterbinden – durch SSI lässt sich somit unverfälschbar sicherstellen, dass es sich um den „richtigen“ Mitarbeiter handelt.
• Regulatorische Konformität: SSI bedeutet echtes „Privacy by Design“ und realisiert regulatorische Anforderungen an die Sicherheit und den Datenschutz, eingebaut und ohne Zusatzaufwand. Die (personenbezogenen) Daten liegen ausschließlich beim Eigentümer, in dessen Wallet auf dem Smartphone oder dem von ihm gewählten Cloud-Dienst – darauf basierend können Freigaben an gewünschte Empfänger getätigt werden. Die zugrunde liegende Blockchain liefert eine eindeutige Transaktionsdokumentation und bietet die Möglichkeit, die Gültigkeit von Credentials jederzeit zu prüfen. Die dezentrale Struktur der Blockchain-Verfahren und das Open-Source-Design aller Softwarekomponenten unterstreichen Verfügbarkeit und Unabhängigkeit.
• Privatsphäre/Diskretion: In der SSI-Welt gibt es für jeden Mitarbeiter eine einzigartige Identität, die auch unternehmensübergreifend genutzt wird – wie im echten Leben. Allerdings wahrt SSI in außerordentlichem Maße die Privatsphäre jedes Nutzers – viel stärker, als es heute in der Handhabung von Online-Accounts und physischen Ausweisen in der realen Welt jemals möglich wäre. Es kann keinerlei Korrelation stattfinden, da für jede Beziehung eine neue, vom Nutzer kreierte Identität (ein DID) erzeugt wird. Der Nutzer baut so sukzessive seine individuelle digitale Identität auf, deren Einzigartigkeit aber allein ihm selbst ersichtlich ist. Dabei profitieren auch Unternehmen vom Schutz der Privatsphäre, die hier Diskretion genannt wird: Genauso wie Credentials nur für die involvierten Parteien einsehbar sind, bleiben auch die Beziehungen zwischen den Parteien diskret.

Der SSI-basierte Ansatz im IAM ist somit schnell, flexibel, sicher, konform und diskret – SSI erleichtert die Digitalisierung drastisch und garantiert gleichzeitig langfristige, nachhaltige Technologiesicherheit. Konsequenterweise sind erste produktive SSI-Umsetzungsprojekte derzeit bereits im Gange (vgl. Kasten).

Top-Themen der SSI-Community

Auch wenn die globale SSI-Community bereits maßgebliche Hürden für den produktiven Einsatz von SSI beseitigt hat, gibt es doch noch Optimierungspotenzial. Die folgenden Abschnitte liefern – basierend auf der Einschätzung des Autors aus seiner Arbeit im SSI-Umfeld – eine Aufstellung der Top-Themen, an denen aktuell gearbeitet wird beziehungsweise die kollektiv als relevant identifiziert wurden:

• Netzwerk-Interoperabilität: Omnipräsentes Thema ist die Fähigkeit, DIDs und Credentials aus verschiedenen Identity-Netzwerken mit einer einzigen Wallet-App verwalten und verwenden zu können. Das ist deshalb wichtig, weil derzeit getrennte Netzwerke in verschiedenen Kontexten entworfen und implementiert werden. Dies erfordert nicht nur Vertrauen in die betreffende Netzwerk-Governance, sondern auch technische Interoperabilität, idealerweise basiert auf gemeinsam definierten und weitverbreiteten Standards. Viele Ressourcen der Community fließen derzeit in die Netzwerk-Interoperabilität.
• Wallet-Backup: Menschen sind es gewohnt, Daten in einer Cloud zu speichern (und zu sichern) und jemanden kontaktieren zu können, falls diese Daten nicht mehr verfügbar sind. SSI in Reinform setzt auf die Nutzung eines Edge-Wallet auf dem Smartphone des Nutzers – das geht mit der Verantwortung einher, selbstständig für die Sicherung der auf dem Gerät gespeicherten Daten zu sorgen. Aus Sicht der Benutzerfreundlichkeit sollte die Backup-Funktion hingegen beim Installieren der App aktiviert werden, „narrensicher“ sein und ausfallfrei funktionieren – Policy-Festlegungen müssen möglich sein, um etwa in Unternehmensszenarien die Aufnahme neuer Daten in die App zu verhindern, falls der Backup-Mechanismus für eine bestimmte Zeitperiode nicht ausgeführt werden konnte.
• Credential-Sync auf dem Gerät: Besonders in der Anlaufphase der breiteren SSI-Nutzung dürften Innovatoren und Early Adopters eigene Wallet-Apps implementieren oder bestehende Apps mit SSI-Wallet-Funktionalität erweitern wollen. Das wird verwirrend für Endnutzer sein, die kaum nachvollziehen können, warum sie mehr als eine Wallet-App benötigen und Credentials in verschiedenen Apps verwalten müssen. Ein Ausweg könnte eine Credential-Synchronisation über verschiedene Wallet-Apps hinweg sein – mit Filterfunktion in einer App für relevante Credential-Typen und einem „Master-Wallet“ zum Anzeigen aller Credentials. Doch dies ist technisch herausfordernd: Gängige Smartphone-Betriebssysteme weisen aus Sicherheitsgründen Einschränkungen im Datenaustausch zwischen Apps auf, was die Implementierung eines Synchronisationsmechanismus erschwert.
• Daten-Schemata: Ein weiteres häufig adressiertes Thema sind Schemata für verschiedene Anwendungsbereiche. In einigen Industrien könnten relevante Datenattribute, Formate und passende Inhalte allgemein bekannt sein. Höchstwahrscheinlich werden jedoch in vielen Szenarien, in denen SSI erstmalig eingesetzt wird, Innovatoren und Start-ups neue Wege beschreiten und eigene Schemata erarbeiten. Sie haben so die Gelegenheit, De-facto-Standards zu schaffen, ohne einen aufwendigen Standardisierungsprozess bedienen zu müssen.
• Verifikation öffentlicher DIDs: In einem geschäftlichen Kontext werden die meisten Organisationen eine öffentliche DID auf dem Netzwerk ihrer Wahl verwenden, um Schemata und Credential-Definitionen zu erzeugen, Credentials auszustellen und allgemein über SSI-Mechanismen erreichbar zu sein. In einem digitalen Vertrauensnetzwerk ist es aber unverzichtbar, zu wissen, mit wem man interagiert. Obwohl eine DID auf einem Identitätsnetzwerk öffentlich ist, wird ihr Eigentümer nicht mit veröffentlicht – dies könnte ohnehin nur eine Selbst-Attestierung sein. Darum ist ein vertrauenswürdiger Bestätigungsprozess für öffentliche DIDs erforderlich, der notwendigerweise in einem verifizierten Organisations-Mapping resultiert. Sinnvoll erweitert haben zwei Systeme ein hohes Potenzial, diese Herausforderung zu adressieren: Global Legal Entity Identifier Information (GLEIF, www.gleif.org) sowie das Dun & Broadstreet D-U-N-S (Data Universal Numbering System, www.dnb.com/duns-number.html).
• Kontrolle über öffentliche DIDs: Eine Transaktion, die über die öffentliche DID einer Organisation ausgeführt wird, ist immer ein offizieller, klar zuordenbarer Akt dieser Organisation. Wie in Bevollmächtigungssituationen üblich, können nur natürliche Personen solche Akte im Namen einer Organisation durchführen. Das Ausüben von Kontrolle über eine öffentliche DID bedeutet daher Macht und erfordert verantwortungsvolles Handeln. Die relevanten geheimen Schlüssel müssen geschützt werden und dürfen nur den rechtlich Befugten zugänglich sein, die für das Unternehmen sprechen dürfen. Die verwandten Begriffe der SSI-Community sind Guardianship (Guardian = Betreuer, Vormund), Delegation und Custodianship (Custodian = Verwalter, Hüter) – zugehörige Konzepte und technische Implementierungen sind in Arbeit. Institutionelle SSI-Agenten mit Zugriffskontrolle sind verfügbar; zukünftig könnten eingebaute technische Methoden für DID-Kontrolle realisiert werden.
• Identitäten von Drittparteien: Einer der großen SSI-Design-Vorteile sind flexible Zertifikate (Credentials), die eine Vielfalt von Anwendungsfällen über Organisationsgrenzen hinweg ermöglichen. Diese erfordern häufig Daten- oder Systemzugriffsmöglichkeiten. In der klassischen Welt muss die Organisation Angestellte von Dritten in die eigenen Identitätssysteme „onboarden“ – ein Prozess, der enorm viel Arbeit, Ärger und Verzögerungen verursacht. Falls die Vertrauensbeziehung es erlaubt, können mit SSI Drittparteien jedoch einfach in die Lage versetzt werden, „ihre“ Identitäten im Bereich der Zielorganisation selbst anzulegen. Da sie am besten wissen, wer für einen Kunden arbeitet, können Repräsentanten des vertrauenswürdigen externen Dienstleisters die im Kundenumfeld aktiven eigenen Angestellten verwalten.

Fazit

Mit SSI tritt an die Stelle zentralistischer Verfahren wie PKI ein flexibles und dynamisches Ökosystem, das verschiedenste Anwendungsgebiete abdeckt. Der mit SSI proklamierte und praktisch realisierte Ansatz eines „Web of Trust“ schafft für jeden Teilnehmer im Netzwerk unmittelbare Anknüpfungspunkte, darunter auch für klassische, zentralistische Instanzen wie Certificate Authorities (CAs) oder Identity-Provider.

Ein SSI-Ökosystem trägt dazu bei, alle Integrationspotenziale effizient und effektiv zu heben. SSI-basiertes IAM bietet beispielsweise maßgebliche Vorteile gegenüber klassischen IAM-Lösungen: Mitarbeiter verschiedener Organisationseinheiten können einfach und schnell Zugang zu IT-Systemen erhalten, ohne die gesamten Personaldaten vorzuhalten oder zu übermitteln. Im einfachsten Fall genügt die Bestätigung der Betriebszugehörigkeit, die sich unkompliziert über das SSI-Ökosystem realisieren lässt.

Die grundlegenden Prinzipien, Funktionen und Wirkmechanismen von SSI sind maßgeblicher Enabler für Digitalisierungsvorhaben aller Art. Der im Kasten auf Seite 67 vorgestellte Fall des Einsatzes von SSI für Enterprise-IAM ist nur ein mögliches Beispiel: Es ist plakativ und eingängig, da praktisch jeder im täglichen digitalen Leben mit meist lästigen Login-Vorgängen konfrontiert wird. Es ist gleichermaßen hochgradig relevant im geschäftlichen Kontext, da die zunehmende Flexibilisierung und Vernetztheit des Arbeitslebens schnellen und unkomplizierten Zugriff für eine Vielzahl von Parteien erfordert.

Der Dreiklang Aussteller–Inhaber–Verifizierer findet sich jedoch in verschiedensten Anwendungsfeldern wieder, sodass ein breitbandiger Einsatz von SSI maximal nützlich und dringend anzuraten ist.

Dr. André Kudra ist CIO der esatus AG.

Literatur

[1] André Kudra, Identity & Access mit der Blockchain, <kes> 2016#5, S. 26
[2] André Kudra, Marcello di Biase und Christopher Hempel, Identity & Access per Blockchain, Ansätze und Projekte in der technischen Diskussion, <kes> 2017#4, S. 25
[3] Drummond Reed, Manu Sporny, Dave Longley, Christopher Allen, Ryan Grant, Markus Sabadello, Decentralized Identifiers (DIDs), Core architecture, data model, and representations, v1.0, März 2020, www.w3.org/TR/did-core/
[4] Pierre-Louis Aublin, Sonia Ben Mokhtar, Vivien Quema, RBFT: Redundant Byzantine Fault Tolerance, in: 2013 IEEE 33rd International Conference on Distributed Computing Systems, ISBN 978-1-4799-0183-8, online verfügbar auf https://pakupaku.me/plaublin/rbft/5000a297.pdf
[5] André Kudra, Sebastian Weidenbach, How to Launch Self-Sovereign Identity Technology for Corporate IT Access, Whitepaper, Februar 2020, https://esatus.com/files/whitepapers/esatus_SSI_Roll-out.pdf
[6] Sovrin Foundation, A Protocol and Token for SelfSovereign Identity and Decentralized Trust, Whitepaper, Januar 2018, https://sovrin.org/library/sovrin-protocoland-token-white-paper