Wieso kann SSI, wie der Turmbau zu Babel enden?
Im Moment ist in der SSI community einiges in Bewegung. Verschiedene technologische Lager gehen aufeinander zu und man entwickelt ein gemeinsames Verständnis, definiert neue Protokolle und Standards. Diese sollen und werden Interoperabilität herstellen und Sicherheits- und Datenschutzprobleme, die man erkannt hat, beseitigen. Dies ist eine überaus positive Entwicklung und man spürt die Aufbruchsstimmung und Euphorie.
ABER dadurch, dass SSI immer mehr Aufmerksamkeit bekommt, Projekte größer werden und die Entwicklung in Richtung Produktivsysteme geht, steigt auch der Druck. Dies bringt eine große Gefahr mit sich, dass überhastet obsolete Protokolle oder/und eigene ad-hoc Lösungen implementiert werden. Auch “SSI” Neueinsteiger wittern ein attraktives Geschäftsfeld und räumen Profit und Marktanteilen Vorrang gegenüber der SSI Idee ein. Dies würde dazu führen, dass Implementierungen nicht interoperabel sind. Im schlimmsten Fall landen wir bei Implementierungen, die mit SSI beworben werden, aber im Grunde proprietäre und zentrale Systeme sind. Man könnte sagen “SSI-washing”.
Ein Begriff Interoperabilität ist in der SSI Community und in Projekten in aller Munde. Aber was bedeutet Interoperabilität für Softwarehersteller wie Jolocom? In diesem Blogpost versuche ich den Begriff zu strukturieren und greifbar zu machen.
Ebenen von Interoperabilität
Der deutsche Eintrag zu Interoperabilität in Wikipedia ist ein guter Startpunkt um die Dinge einzuordnen (link). Darin wird zwischen struktureller-, syntaktischer-, semantischer- und organisatorischer Interoperabilität unterschieden.
- Strukturelle Interoperabilität bezieht sich auf den Austausch von Daten,
- Syntaktische auf die Extraktion der Daten,
- Semantische auf die Interpretation und
- Organisatorische bezieht sich auf die Prozesse.
Das Ziel ist klar, wir wollen, dass verschiedene Komponenten in einem SSI System miteinander kommunizieren und Daten austauschen können. Des Weiteren ist es wichtig, dass sie diese Daten auch extrahiert werden können, damit sie danach semantisch interpretiert werden können.
Die Unterscheidung zwischen Syntax und Semantik kann schwierig sein. Das folgende Beispiel ist ein Auszug aus dem W3C Verifable Credential Data Model. Anhand diesem erläutere ich den Unterschied.
"name": "Jayden Doe",
Auf der syntaktischen Ebene, weiß ich nur, dass der erste Begriff "name" ein Attribut ist und der zweite "Jayden Doe", der Wert. Ich weiß aber nicht was es bedeutet. Auf der semantischen Eben weiß ich, dass das Attribut den Namen darstellt und der Name “Jayden Doe” ist.
Semantische und organisatorische Interoperabilität liegen in der Einflusssphäre des jeweiligen Anwendungsfalls und sind von der eigentlichen Softwareherstellung zum größten Teil unabhängig. Daher ist für die weitere Betrachtung die strukturelle und die syntaktische Interoperabilität von Relevanz.
Wie kann man Interoperabilität herstellen?
Wie kann strukturelle und syntaktische Interoperabilität hergestellt werden? Dafür gibt es verschiedene Wege. Man kann, vereinfacht gesagt
- eine einheitliche Software verwenden oder
- Protokolle und Standards definieren oder
- “Middelware” entwickeln die zwischen den verschiedenen Systemen als Übersetzer agiert.
Um die passende Möglichkeiten auszuwählen, muss man sich Ziele und Rahmenbedingungen vor Augen führen.
Was sind die Ziele von SSI und welcher Weg leitet sich dadurch ab?
SSI oder dezentrale Identitäten soll eine öffentliche digitale Plattform für alle sein. Es muss open source und für alle zugänglich sein. Mit diesen Zielen fällt die erste Möglichkeit weg. Eine einheitliche Software für alle würde eine sehr starke Beschränkung darstellen. Innovation würde nicht gefördert werden und der Zugang könnte eingeschränkt werden.
Ein wichtiges weiteres Ziel von SSI ist der Datenschutz, eine Middleware (Übersetzer), also die dritte Möglichkeit, würde dieses Ziel gefährden. Wenn die Kommunikation über einen Übersetzer stattfindet, muss dieser alles mithören, sonst kann er nicht übersetzen. Es muss auch nicht auf bestehende SSI Systeme in Produktion Rücksicht genommen werden. Altlasten und viele verschiedene Systeme sind oft Grund für den Einsatz von Middleware.
Was bleibt also Möglichkeit Nummer zwei. Man muss sich auf einheitliche Protokolle und Standards einigen. Nur so kann sichergestellt werden, dass es keine Einschränkung auf einen Hersteller gibt, der Datenschutz sichergestellt ist und alle Implementierung miteinander sprechen können und somit interoperabel sind.
Wir müssen uns alle gemeinsam anstrengen, dass wir bei einer Sprache bleiben und den SSI Turmbau vollenden.
Wenn Interesse besteht, kommt zum 33. Internet Indentity Workshop vom 12-14. Oktober (Onlineevent). Wir werden eine Session zum Thema halten, um das Thema in der Community zu diskutieren.