In den Vorbereitungsgesprächen für unseren Vortrag auf der diesjährigen Konferenz der Cloud Storage Services for Synchronization and Sharing (CS3) haben wir auch kurz über das Solid-Projekt gesprochen. Und da Solid sehr gut zu unseren Werten der Kontrolle über Ihre Daten und der digitalen Souveränität passt, hatten wir die Idee, einige der diskutierten Ideen in einem Blog zusammenzufassen.
Was ist Solid?
Solid ist ein Projekt unter Leitung von Sir Tim Berners-Lee, dem “Erfinder des Webs”. Ziel des Projekts ist es, eine Infrastruktur aufzubauen, in der Benutzer ihre Daten sicher und dezentral in sogenannten “Pods” speichern können. Der Zugriff auf die Daten innerhalb eines Pods erfolgt über das “Solid Protocol“, das auch dafür sorgt, wer genau Zugriff auf diese Daten hat.
Neben der Bereitstellung von einfachen Dateien wie Bildern, Videos und Dokumenten ist es das Ziel von Solid, die Idee des “Linked-Data-Modells” voranzutreiben, also die Speicherung von Daten in offenen, standardisierten Formaten, die maschinenlesbar sind und es erlauben, die Daten mehrerer Nutzer sinnvoll zu verknüpfen.
Was würde das für die Kopano Groupware bedeuten?
Betrachtet man die aktuelle Kopano-Architektur, so gibt es zwei Stellen, an denen ein solcher Pod eingesetzt werden könnte. Der erste Pod wäre Teil von Kopano Konnect, welches die Identitäten verwaltet und bereits ein OpenID Connect basierter Authentifizierungsanbieter ist. Hierfür müsste Konnect um die Funktion WebID erweitert werden, die die in Solid verwendete Authentifizierungsschicht ist. Glücklicherweise gibt es mit WebID-OIDC eine WebID-Variante, die bereits vollständig auf OpenID Connect basiert.
Der zweite Platz für einen solchen Pod wäre an der Seite des kopano-Servers, der den Zugriff auf Ihre Groupware-Daten verwaltet. Dies könnte eine neue Komponente sein, die eine minimale Teilmenge des Solid-Protokolls veröffentlicht und den übrigen Datenaustausch könnte man dann mit der Microsoft Graph-kompatiblen RestAPI von Kopano erledigen. Mit diesen beiden Komponenten wären Kopano-Benutzer nicht nur in der Lage, sich bei Anwendungen anzumelden, die Solid für dezentrale Anmeldungen unterstützen, sondern auch ihre Daten in diesen Anwendungen zu verwenden.
Anwendungsbeispiel: Planung von Gruppenmeetings
Für One-to-One-Meetings haben wir vor Kurzem bereits über Harmonizely gebloggt, das Kopanos RestAPI nutzt, um Zugriff auf Ihren Kalender zu erhalten und somit jemandem, der ein Meeting mit Ihnen planen möchte, nur noch freie Termine vorschlägt. Benutzer können auf der gleichen Kopano-Installation die Frei/Gebucht-Daten verwenden und leicht erkennen, wann andere Benutzer für ein Gruppenmeeting frei wären. Aber was passiert, wenn Sie Gruppenmeetings mit externen Teilnehmern planen möchten?
An dieser Stelle könnte Solid ins Spiel kommen. Es gibt bereits Open-Source-Apps wie Framadata, aber alle diese Apps erfordern, dass ein Organisator Termine manuell eingibt und die Teilnehmer ihre Kalender manuell überprüfen und eine Option auswählen, die ihnen am besten passt. Mit einer föderierten Identität und Kalenderdaten, auf die über Solid zugegriffen werden kann, könnten die Teilnehmer des besagten Meetings ihre eigene Identität verwenden, um sich bei einer solchen Planungs-App anzumelden und der App Zugriff auf ihre Termindaten zu geben, wobei automatisch Termine vorgeschlagen werden, die in ihren Kalendern noch frei wären. Für zukünftige Meetings könnte die App sogar den Zugriff auf die Terminkalender der Nutzer behalten, um direkt Termine auszuschließen, die nicht in den Terminkalender der einzuladenden Nutzer passen würden.
Anwendungsbeispiel: File-Sharing
Es gibt bereits viele Lösungen, die das einfache Teilen von Dateien unterstützen, wie ownCloud, Seafile und Nextcloud. Diese erlauben es in der Regel einem Benutzer, einen Link zu einem Dokument zu teilen und optional den Link mit einem Passwort zu schützen. Würde man eine dieser Lösungen mit einer föderierten Identität integrieren, müsste man keinen anonymen Link verschicken, sondern könnte stattdessen einen Link verschicken, der nur von einer bestimmten föderierten Identität geöffnet werden kann. Basierend auf dieser Identität könnte der Benutzer festlegen, was der Empfänger mit der freigegebenen Datei tun darf, wie z.B. nur Lesezugriff oder sogar Schreibzugriff, um sie an einem zentralen Ort zu aktualisieren.
Fazit
Heutzutage werden Daten an vielen Orten gespeichert und leider hat man entweder eine eigene Insel der Authentifizierung oder man muss einem der wenigen großen Tech-Konzerne (wie Google, Facebook, Microsoft und Amazon) vertrauen, die die Identität für einen verwalten. Solid kann nicht nur dabei helfen, das Eigentum an den eigenen Daten zu sichern, sondern kann mit seiner dezentralen Identität auch dabei helfen, Systeme und Daten zu verbinden, die sonst in einem eigenen Silo bleiben würden.
