 Als ersten Speaker darf ich Martin begrüßen. Martin wird uns eine Idee vorstellen, wie man das Internet retten könnte bzw. besser machen könnte. Herzlich willkommen Martin, deine Bühne. Danke. Ja, hallo. Vielen Dank erst mal, dass ich da sein darf und dass es heute für mich einen Vortragslot gibt zu dem Thema Reclaim ID, das ich vorstellen möchte. Kurz zu mir, ich bin Dr. Rand am Fraunhofer bzw. Tio München und arbeite auch am Gnudet-Projekt mit, das vielleicht öfter schon mal hier auch zu Gast war in den letzten Jahren. Genau und heute werde ich mal kurz was zu Reclaim ID sagen und zunächst mal etwas zur Motivation, warum wir dieses Projekt überhaupt oder dieses Tool, warum wir uns da Gedanken drüber gemacht haben. Das ist ein Bild, das zeige ich eigentlich relativ gerne, das zeigt sozusagen, wo Nutzeidentitäten momentan verteilt sind. Das heißt, wo sind die großen Teils gespeichert. Auf eigentlich Webseiten speichert fast niemand mehr seine Profile. Über 60 Prozent aller Nutzeidentitäten sind bei Facebook gespeichert, gefolgt bei Google, 20 Prozent, Twitter und dann im Abseits schon eher so Yahoo und LinkedIn. Was man hier eben sehen kann ist, dieser Markt oder die Datenhaltung an digitalen Identitäten ist sehr stark monopolisiert und sehr stark zentralisiert auch auf einzelne kommerzielle Anbiete. Und natürlich kann man das kritisch sehen und das sind auch ein paar Probleme, die wahrscheinlich auch für euch mehr oder weniger offensichtlich sind. Zuerst sind Privacy Probleme. Also diese Zentralisierung der Identitäten ist natürlich mehr oder weniger eine Goldgrube für diese Dienstanbiete, für Werbung, um aber auch Meinungsbildung zu betreiben, ist das natürlich perfekt, so einen Datenschatz zu haben. Andererseits ist es natürlich auch so, dass für Überwachung und Datensammlung diese zentralen Identitäten und damit auch ihre Bewegungen im Internet auch eine Goldgrube sind. Heute habe ich es gelesen, gestern war wieder ein Artikel in der New York Times, da ging es um so ein Gerichtsverhandlung, die die Electronic Frontier Foundation gewonnen hat, dass FBI anscheinend viel mehr Nutzeidentitäten oder National Security Letters an Diensteanbieter rausgibt, als erwartet war zu Beginn. Also ein Artikel, den kann man sich gerne mal durchlesen, der ist sehr erschreckend. Das heißt, diese Zentralisierung ist ein sehr großes Privacy Problem. Neben dem Privacy Problem hat man aber eigentlich auch noch in gewisser Weise ein Problem, dass diese Zentralisierung der Daten ist eigentlich für die Diensteanbiete auch nicht optimal, genauso wie für Website. Insbesondere, wenn man mal über die Datenschutzgrundverordnung oder auch das GDPR überlegt, wenn diese Daten tatsächlich alle an einem Ort sind, dann braucht es eigentlich nur einen Heck, bis sie alle wegkommen. Und das können auch existenzbedrohende Liabilities sein, die man da hat. Und schließlich scheint es so, dass dieses insbesondere das Identitätsmanagement oder die Verwaltung der Identitäten ein Oligopol ist. Das heißt, es gibt eben nur einen oder in dem Fall jetzt zwei. Und obwohl es Identitätsförderierungen oder Systeme um Identitäten verteilt zu speichern schon seit Jahrzehnten gibt, scheint dieses Ökosystem immer zu degenerieren hin zu einzelnen großen Identitätsprovidern, wie es eben momentan der Fall ist. Was natürlich nicht optimal ist. Wie kann man jetzt dagegen ankämpfen? Unsere Idee war, um dieses Problem zu lösen, um diese Privacy-Probleme und diese Gefahren zu mitigieren, müssen wir eigentlich den Nutzern die Kontrolle über Identitäten komplett zurückgeben. Das heißt, Identitäten und Identitätsprofile verbundene Attribute, die sollten nicht irgendwie bei einem Dienstleister, insbesondere bei einem kommerziellen Dienstleister gespeichert werden, sondern der Nutzer sollte es über sie selbst verfügen. Das würde schon mal das ganze Problem der zentralen Datenhaltung lösen. Und es wäre auch für eine Website-Beispose viel besser, wenn sie das nicht alles speichern müsste. So eine Art von Software oder so eine Art von Dienst muss aber natürlich frei zugänglich für jeden sein und per Definition dezentralisiert sein oder zumindest verteilt auf die Nutzer, weil sonst haben wir dasselbe Problem wie vorher wieder. Und natürlich sollte der Betreiber des Services, wenn es überhaupt jemandem gibt, kein, nicht wieder ein Geschäftsmodell haben, dass diese Daten in irgendeiner Art und Weise monetarisieren möchte. Das heißt, im Endeffekt sollte das freie Software sein und idealerweise natürlich dezentrales Software. Daher kommt auch im Endeffekt der Name, wir wollen sozusagen die Nutzer bestärken und den Nutzern Tools an die Hand geben, um eben die Kontrolle über die eigenen Identitäten wiederzuerlangen. Deswegen eben auch Reclaim. Um jetzt erstmal einzusteigen, was es jetzt genau ist, was ich mir sicher vorstellen will, möchte ich noch mal kurz sagen, was diese Identitätsprovider, also wie beispielsweise Google oder Facebook, eigentlich für Nutzer oder Website bieten oder warum man sie überhaupt hat und warum sie nützlich sind. Also nächstes Mal erlauben Sie es, dass sich meine digitalen Identitäten oder digitale Identität überhaupt verwalten kann. Also es ist ein Tool, mit dem ich meine Identitäten verwalten kann und meine persönlichen Daten. Und noch viel wichtiger, ich habe eine zentrale Identität, die ich jetzt mit den eigentlichen Websites, mit denen ich interagieren möchte, sei es ein Webshop, sei es ein Forum, vollkommen egal. Ich kann sozusagen mit anderen Websites, die ich sonst eigentlich im Alltag benutzt, diese Daten teilen und kann mich da authentisieren. Und muss nicht sozusagen bei jeder Website eine eigene Identität anlegen und da meine Daten wieder verwalten, dann habe ich überall meine Schattenidentitäten, das ist eben ein bisschen ungünstig. Für Websites selber ist der Vorteil eben zusätzlich noch da, selbst wenn ich mit dem Nutzer nicht interagiere, kann ich immer noch aktuelle Informationen über die Identitäten aus diesen Diensten ziehen. Also beispielsweise, wenn ich jetzt eine Mailingliste betreibe, dann braucht diese Mailingliste zu dem Zeitpunkt, wenn E-Mails geschickt werden, eine aktuelle E-Mail-Adresse. Und das ist natürlich nützlich, wenn ich irgendein Dienst habe, wo ich die aktuelle E-Mail-Adresse rauslesen kann. Und dafür sind diese Dienste eben da. Und die Autorisierungsentscheidungen, die der Nutzer trifft, können eben dann zentral an Identitätsproviders durchgesetzt werden. Das Zweite, was Identitätsproviders machen, und das ist eigentlich ihre Kernaufgabe von dem Identitätsproviders, ist, dass sie die Identitätsinformationen attestieren und verifizieren. Das heißt, sie sagen, diese E-Mail-Adresse ist tatsächlich korrekt oder diese Person lebt tatsächlich hier. Das ist eigentlich das, was Autoritäten über gewisse Identitätsattribute machen sollten. Mittlerweile ist es allerdings nicht so, weil die Identitätsproviders, die wir gerade vorhin gesehen haben, das sind ja eigentlich gar nicht Autoritäten über beispielsweise eine E-Mail-Adresse oder über einen Namen, wie jetzt jemand genau heißt. Trotzdem tun sie das. Für das, was ich heute vorstellen will, oder was wir primär jetzt zunächst lösen wollen, ist der erste Teil. Der erste Teil ist diese Dienstleistung, die hier erbracht wird in Bezug auf der Nutzer möchte seine Daten teilen und Webseiten möchten eben diese Daten, Zugriff auf diese Daten bekommen und der Nutzer soll eben diese Autorisierungsentscheidungen fällen können. Der zweite Teil ist jetzt nicht direkt Teil des Systems, aber trotzdem relevant und ich werde da nochmal später darauf zu sprechen kommen, wie man das lösen kann. Also, was ist jetzt eigentlich das Reclaim-ID, über das ich heute sprechen möchte? Reclaim-ID ist ein sogenanntes Self-Sovereign-Identitiesystem, das hat vielleicht jemand von euch schon mal gehört. Das ist ein bisschen in Mode zurzeit, insbesondere jetzt im Zuge des Blockchain-Hypes. Es ist so ähnlich vom Konzept hier, wie die Ideen von Sovereign, U-Port, Name-ID, das sind vielleicht Sachen, die man gehört hat, wenn man sich ein bisschen in der Blockchain-Umgebung auskennt. Sovereign ist eine permissioned Blockchain, d.h. es ist im Endeffekt eine Föderation aus näher Firmen, die diese Blockchain im Endeffekt verwalten, was auch nicht optimal ist, weil das ist eben nicht dezentralisiert auf Stakeholder, die jetzt nicht die Daten kommerzialisieren wollen. U-Port hat sich über die letzten Jahre, würde ich jetzt mal sagen, stark geändert. Die ursprüngliche Idee war ziemlich interessant. Momentan dient U-Port eigentlich gar nicht mehr so sehr, die Daten auf einer Blockchain oder über eine Blockchain zu teilen, sondern ist mehr oder weniger nur eine App, mit der ich Daten direkt mit einer Website teilen kann. Und dann hat die Blockchain nur ein paar Zusatzfunktionalitäten. Name-ID ist das älteste davon. Name-ID ist ein System, ist eigentlich ein Namensystem, nicht Namecoin. In diesem Namenssystem konnte man Identitätsattribute ablegen, also beispielsweise eine E-Mail-Adresse. Und aus irgendeinem Grund, der mir jetzt auch nicht komplett klar ist, haben sie sich dann entschieden, um auf diese Daten zugreifen zu können als Website und als Nutzer, hat man das über einen zentralen Server gemacht, was eigentlich die komplette Idee dazu nicht gemacht hat. Weiterhin war das Problem, das hatte U-Port auch ursprünglich, dass die Daten, die man dann in diese Blockchain abgelegt hat, die konnte natürlich jeder lesen. Deswegen war auch dieser Zugriffsserver eigentlich redundant, weil man konnte einfach direkt in der Blockchain nachschauen, was denn jetzt das Attribut war. Unsere Idee braucht keine Blockchain. Eigentlich ist es überhaupt nicht notwendig, eine Blockchain zu haben, außer da wird man sagen können, dass wir eine Blockchain haben. Es ist aber trotzdem voll dezentralisiert und es erlaubt asynchronen Zugriff auf die Daten. Das bedeutet, selbst wenn der Nutzer, also wenn der Nutzer mal seine Daten geteilt hat, mit einer Website beispielsweise, dann kann dieser Website auf diese Daten auch zugreifen, wenn der Nutzer gerade nicht online ist. Wenn der Nutzer jetzt irgendwann mal seine Daten ändern sollte und dann wieder offline geht, dann hat die Website trotzdem Zugriff auf den aktuellen Daten. Also das ist so die Anforderung, die wir erfüllen wollen, auch ohne Blockchain. Zusammengefasst oder ganz high-level ist ReclaimID eigentlich ein sogenannte dezentralisierter Verzeichnestdienst. Komm ich gleich noch mal drauf, was das ist. Das kennt glaube ich eigentlich jeder. Kombiniert mit einer kryptografischen Zugriffskontrolle. Was ist ein Verzeichnestdienst? Die meisten kennen Verzeichnestdienste laut Standard X500. Das ist sowas wie LDAP oder Active Directory. Das sind so die Sachen, die man sich als Server eigentlich hinstellt. Die meisten zentralen Identitätsprovider, wie die, die wir genannt haben, benutzen eigentlich solche Verzeichnestdienste allerdings natürlich in ihren eigenen Rechenzentrum als zentrale Datenhaltung. Es gibt auch verteilte Verzeichnestdienste, wie beispielsweise Namensysteme. DNS ist das bekannteste. Also viele Leute haben DNS nicht als Verzeichnestdienst abgespeichert, aber DNS kann eigentlich ja mehr als nur IP-Adressen speichern, sondern eigentlich beliebige Einträge. Zu diesen Verzeichnestdiensten gehört auch Namecoin. Das hatten wir gerade bei NameID. Aus dem Grund ist es ja eigentlich auch eine gute Idee von NameID gewesen, sozusagen ein verteiltes Verzeichnest zu nehmen, um Identitätsattribute zu speichern. Sie hatten nur das Problem mit der Zugriffskontrolle. In Reclaim ist das dezentralisierte Verzeichnest ein dezentralisiertes Namensystem auch, und zwar das GNU Name System, das in GNU nicht implementiert ist. Die Idee ist eben wie schon erwähnt ein bisschen geborgt von NameID und verbessert. Was bedeutet das, wenn man sozusagen seine Identitätsattribute in einem Namensystem abspeichert? Man kann eben beispielsweise mit Tools wie NSLookup oder eigentlich sogar mit dem Browser oder Betriebssystem Tools dann kann man eben einen gewissen Namen, wie beispielsweise email.bob.org, auflösen zum eigentlichen E-Mail-Adresse, bobbytexample.com. Das könnte man eben jetzt auch mit dem Namen machen oder mit der Adresse oder wie auch immer. Und diese Informationen werden jetzt nicht zentral bei einem Server gespeichert, sondern eben von bob dementsprechend, wo er es hinterlegen möchte oder in seinem Namensraum würde man sagen für Namenssysteme. Um den Zugriff jetzt zu steuern, hier möchte ich noch vorwegnehmen, ich habe den Talks dieses Jahr schon mal, Anfang dieses Jahres, gehalten. Die kryptografischen Grundlagen haben sich jetzt ein bisschen geändert. Sie benutzen sozusagen die Verschlüsselung von GNS, um Nutzerdaten zu schützen und deren Integrität zu schützen. Da komme ich jetzt im Detail nochmal später drauf, wie das genau funktioniert. Auf aller Fälle erlaubt uns, erlaubt uns ein Kniff, wie man sozusagen das GNS benutzen kann und wie die Verschlüsselung darin funktioniert, die Zugriffskontrolle zu realisieren, auf Daten, die dezentral in diesem Verzeichnis gespeichert sind. So, wie funktioniert es? Also prinzipiell kann man sich vorstellen, wenn man jetzt ein Nutzer ist, sitzt man an seinem Computer, tippt da über ein Nutzerinterface, über ein Browserplaggen oder wie auch immer seine Identitätsdaten ein. Das heißt, man schreibt eben auf, hier meine E-Mail-Adresse ist so und so, mein Geburtsdatum, meinen Namen. Diese Daten werden jetzt erstmal nur lokal verarbeitet, auf seinem eigenen Rechner. Dann wird ReclameID diese Daten nehmen, sie verschlüsseln und ins dezentrale Verzeichnis ablegen. Hierfür muss man jetzt wissen, wie GNS diese Daten ablegt. Also in GNS, jetzt kommt ein bisschen Krypto und Mathe, also falls es ein bisschen schwierig ist, kann man auch einfach den Text, der gleich kommt, akzeptieren. Das wird auch reichen. Also in GNS, ein Namensraum, wird identifiziert durch ein Public-Private-Keeper. Hier werden elliptische Kurven benutzt, das heißt, wir definieren X ist ein privater Schlüssel, groß P ein öffentlicher Schlüssel, G ist der sogenannte Generator der Kurve und N ist die Ordnung der Gruppe in diesem System. Das wird jetzt später noch wichtig für die Krypto selbst. Die Einträge, also beispielsweise jetzt die E-Mail-Adresse, werden verschlüsselt unsigniert mit einem Schlüssel der abgeleitetes von X und P. Die verschlüsselten Einträge werden dann veröffentlicht in einer sogenannten Distributed-Hash-Table. Eine Distributed-Hash-Table ist im Endeffekt eine verteilte Datenstruktur, die es mir erlaubt, unter einem bestimmten Schlüsselwert, also beispielsweise A, irgendeinen Wert abzulegen. Also zum Beispiel jetzt die E-Mail-Adresse. Das ist eigentlich alles, was Namensysteme machen. Namensysteme erlauben es sozusagen, unter einem bestimmten Namen einen bestimmten Wert abzuspeichern und jemand anders kann dann für diesen speziellen Namen diesen anderen Wert abrufen. Das ist eben auch, was hier passiert. Den Namen, unter dem ein Eintrag gespeichert wird, nennen wir Q. Da GNS ein dezentralisiertes System ist, bedeutet es, dass diese Speicheranfrage jetzt erstmal durch das Netz wandert. Der GNS ist jetzt so, dass jedes Pier, dass diese Speicheranfrage sieht, die Signatur, die Signatur verifizieren kann. Es wird eine Signatur generiert, von einem Abgleiter im Schlüssel. Es ist aber nicht möglich, für dieses Pier diese Daten zu entschlüsseln, außer er weiß, für welchen Public Key und für welchen Namen, also für welchen Key dieser Eintrag abgespeichert wurde. Das ist ein Feature, das hat GNS, das haben Namensysteme wie Namecoin jetzt nicht. GNS hat das eigentlich sogar, aber es ist sozusagen bei GNS nicht möglich, dass ich einfach das Netzwerk beobachte und sehe, oh, da speichert jemand jetzt unter diesem Namen diesen Wert ab. Weil der Wert ist verschlüsselt und der Name unter dem es gespeichert wird. Also ich könnte nicht suchen nach allen Records unter P beispielsweise. Und ich müsste genau wissen, welcher Name wurde denn jetzt genau abgespeichert, damit ich den eigentlichen Eintrag finde. Im Endeffekt heißt es, die Namen sozusagen, die eine Identität abspeichert in GNS, die können nicht durchintodiert werden. Das heißt, ich kann nicht sagen, gib mir doch mal alle Einträge für die Identität X oder für den Public Key P und gleichzeitig können auch externe Beobachter das nicht sehen, was jetzt genau gespeichert wird. Außer natürlich, sie kennen den Namen und den jeweiligen Namensraum. Dieses High Level Feature können wir ausnutzen, indem wir einfach definieren, dass der Name unter dem wir speichern eigentlich ein Passwort ist. Das heißt, man kann nur diese Informationen auflösen, wenn man das Passwort kennt. Wie würde das aussehen? Man ist ein Nutzer und speichert jetzt E-Mail, Name und sein Geburtsdatum ab. Dann ist sozusagen das, was man abspeichert als Wert, sind eben die Daten der E-Mail-Adresse, Name, Geburtsdatum und der Name unter dem man es publiziert. Also das Label, wie man es nennt, bei Namenssystemen. Das sind im Endeffekt Passwörter. Das sind zufällig gewählte Werte, die nicht ratbar sind, die kann man jetzt auch nicht einfach irgendwie durchprobieren finden. Also man könnte sie schon, aber es ist sehr aufwendig. Das heißt, man kann sich vorstellen, wie bei pwgen, man generiert sich einfach Passwörter für jedes Attribut und speichert die Identitätsattribute unter diesem Passwort ab. Was passiert da dann bei gns? Also was gns zunächst mal macht ist, es hascht unser Passwort und den Public Key unseres Namensraums. Dann hascht es wiederum diesen Hasht zusammen mit dem Public Key. Das ist jetzt unser DHT Key. Das heißt, das ist der Schlüssel, unter dem die Daten gespeichert werden. Also um Q zu wissen oder um Q mir selber zu bauen, muss ich H kennen und P. Dann wird ein Schlüssel abgeleitet, einerseits von unserem Passwort und auch wiederum von P. Das heißt, wieder muss man P und das Passwort kennen, um ein Schlüssel zu bekommen und die eigentlichen Identitätsinformationen, also die Daten, wie beispielsweise die E-Mail Adresse, werden mit diesem Schlüssel verschlüsselt. Zusätzlich werden diese Daten dann auch noch mit einem abgeleiteten Schlüssel signiert. Da wird man noch die Signatur prüfen kann. Also ist es tatsächlich die Identität, zu der dieses Datum gehört. Aber der interessante Punkt hier ist eben, die einzige Möglichkeit, wie ich diesen DHT Schlüssel bekommen und die Verschlüsselung machen kann ist, indem ich das Passwort kennen, in dem Fall L Adre und P. Ohne diese Informationen habe ich keine Möglichkeit, Records zu entschlüsseln. Ich habe keine Möglichkeit sie zu finden im dezentralen System. Okay, mal angenommen. Der Nutzer hat es jetzt getan. Also der Nutzer hat sozusagen in seinen Interface irgendwie seine Identitäten eingegeben und Reclaim hat das dann alles für ihn erledigt und diese Informationen unter Passwörtern im dezentralen Verzeichnestienst veröffentlicht. Was er jetzt machen kann ist, er autorisiert eine Website dazu auf diese Daten zuzugreifen. Naiv könnte man sich jetzt überlegen, okay, ich gebe dieser Website alle diese Passwörter für meine Attribute. Und das würde auch ohne Probleme funktionieren. Also ich gebe der Website einfach alle meine Attributspasswörter und die Website kann jetzt die Informationen aus dem dezentralisierten Verzeichnis auflösen und entschlüsseln. Das Problem ist, dass ich dann aber bekommen würde ist, wenn ich jetzt mehrere Webseiten habe, dann muss ich diesen Webseiten allen die Passwörter geben und wenn ich jetzt einer dieser Webseiten den Zugriff entziehen möchte, dann habe ich ein Problem, weil jetzt muss ich meine Passwörter ändern. Das heißt, die Idee ist, dass wir da eine Indirektion reinbauen. Wir haben also unsere Attribute in unserem Namensraum abgespeichert. E-Mail, Name und Geburtsdatum. Und was wir jetzt machen ist, wir fügen noch einen Eintrag hinzu, das nennt man bei Rickleim das Ticket, und dieses Ticket enthält die Passwörter für die Attribute, auf die ich Zugriff habe. Das heißt, wenn ich jetzt eine Website Zugriff gebe auf meine Daten, dann generiere ich so einen Eintrag, wieder L-Ticket, das ist in dem Fall wieder ein Passwort und unter diesem Passwort speichere ich jetzt Referenzen auf die Attribute selbst, also bzw. die Passwörter auf die Attribute. Den Vorteil, den ich jetzt habe, ist, möchte ich für eine Website oder irgendeinen Interessenten den Zugriff reduzieren, also den Zugriff zurücknehmen auf diese Attribute. Was ich jetzt machen kann ist, ich lösche einfach den Ticket-Eintrag, dieses Passwort wieder aus dem Namenssystem raus und ändere die Passwörter für alle Attribute. Für alle anderen Websiten, die noch Zugriff haben auf die Attribute, für die kann ich einfach die Referenzen in ihren Tickets ändern. Also auf diese Indirektion habe ich den Vorteil, dass ich effizient Revocation machen kann. Das ist eigentlich der einzige Grund. Prinzipiell würde es reichen, wenn ich den Websiten direkt die Passwörter auf die Attribute gebe. Also mal angenommen, ich habe eine Website autorisiert, auf meine Daten zuzugreifen. Das bedeutet im Endeffekt, ich habe dieser Website das Passwort für sein Ticket gegeben. Wie bekommt es jetzt die Daten? Naja, es macht im Endeffekt das Gleiche, wie als der Nutzer die Daten gepublished hat. Es berechnet sich das H, weil es kennt ja sein Ticket und die Identität, um die es geht. Dann kann es sich den DHT-Ki ausrechnen, indem es einfach wieder ein Herrscher über H und P bildet. Und es kann sich über L und P, der L-Ticket und P den Schlüssel ausrechnen, um die veröffentlichten Daten zu entschlüsseln. Das ist natürlich alles sehr technisch. Der Nutzer will ja sich eigentlich wieder mit irgendwelchen Schlüsseln oder mit irgendwelchen Passwörtern oder sonstiges rumärgern. Man kann sich das vorstellen, dass es eigentlich komplett abstrahiert. Das heißt, für den Nutzer kann man sich ausrechnen, wie jeder andere, ob man die Connect-Login, also ob man die Connect kennt, das gibt meistens so Knöpfe, Login mit Google. Man kann sich das genauso vorstellen, da steht eben nicht Login mit Google, sondern Login mit Reclaim-ID. Wenn man da draufklickt, dann kommt man eben auf eine Website, die lokal auf seinem Rechner läuft. Dort kann man seine Attribute verwalten und eben den Zugriff auf die Daten kontrollieren. Das heißt, wenn man den Zugriff gestattet von einer Website, dann sieht es genauso aus wie bei Google. Man klickt irgendwie auf Autorisieren, dann steht da die Seite, möchte auf Attribute, E-Mail und Name Zugriff haben. Dann kann man eben sagen, ja oder nein. Und innerhalb des Open-Edit-Connect-Protokolls schicken wir einfach diese Metadaten mit die Websiten brauchen. Also beispielsweise können wir das Ticket-Passwort mitschicken. Die Website selber kann dann auch ganz normal über das Open-Edit-Connect-Protokoll diese Nutzerinformation abrufen. Also sowohl für Nutzer als auch für Websites ist diese ganze Technik versteckt. Das heißt, die müssen eigentlich hier nichts tun. Zu diesem Zeitpunkt hätte ich jetzt eine Demo gezeigt. Leider hatte ich die geniale Idee, jetzt hier diesen Laptop zu nehmen. Falls jemand eine Demo sehen möchte, danach ist es gleich ein Workshop, wo ich das gerne zeigen kann. Das habe ich jetzt hier eben nicht installiert. Da kann ich es nicht zeigen. Aber dann kann man das auch sehen, dass es im Endeffekt genauso aussieht so ein Loginflow wie bei einem Login mit Google. Das wäre die Idee. Jetzt würde ich noch gerne auf einen anderen Aspekt zu sprechen kommen. Was ich ursprünglich gesagt habe, nämlich die Intest-Probyte attestieren ja normalerweise die Attribute. Das heißt, wenn ich jetzt meine E-Mail-Adresse in dieses System eingebe dann weiß die Webseite ja gar nicht, ob das meine E-Mail-Adresse ist oder ob das überhaupt eine gültige E-Mail-Adresse ist. Und dieses Problem ist ja eigentlich existent, weil das ist ja der Grund, warum man auch so etwas wie E-Mail-Vertifikation machen muss. Das heißt, diese dritten Parteien, also beispielsweise Webseiten, brauchen manchmal Attestierungen von dritten Parteien über eine bestimmte Identitätsinformation. E-Mail ist ein sehr gutes Beispiel. Die dritte Partei, die tatsächlich sagen kann, dass dies die E-Mail-Adresse eines Nutzers ist, ist eigentlich mein E-Mail-Provider. Das heißt, je nachdem welchen E-Mail-Provider ich hab und je nachdem welche E-Mail-Provider meine E-Mails für mich verwaltet und meine E-Mail-Adressen, das ist die Entitität, die eigentlich sagen kann, ja, das ist die E-Mail-Adresse für diesen Nutzern. Wird sie weiß es so, dass momentan Identity-Provider uns auch mit dieser Verifikation, na ja, wie soll man sagen, es sieht so aus, als wer die Information, die von diesen Identitätsprovidern kommt, tatsächlich unter deren Autorität, also beispielsweise ein Nutzername, klar. Der ist wahrscheinlich unter der Autorität von den jeweiligen Diensten. Bei der E-Mail-Adresse wird es schon schwierig. Bei Google könnte man argumentieren, gut, das ist die E-Mail-Adresse, das heißt, sie sind tatsächlich auch der Mail-Provider. Natürlich, dann Namen, Namen, Telefonnummern. Klar, die können von diesen Identitätsprovidern verifiziert sein, aber sie sind definitiv nicht die Autoritäten über diese Information. Aber natürlich ist es ein Dienst sozusagen, den sie auch bieten und sie sagen, na ja, wir haben sozusagen diese Telefonnummer und diese E-Mail-Adresse für dich verifiziert. Aber eigentlich sind es nicht die Provider dieser Information. Deswegen, das ist unsere, erst mal nur eine Aussage, sozusagen, diese Parteien sind eigentlich nicht die Autoritäten darüber und es gibt noch viel mehr Beispiele, wie alt man ist, was der konkrete Name ist, wo man wohnt, was man für eine Nationalität hat, was man für eine E-Mail-Adresse hat. Das heißt, eigentlich ist es ja so, dass für seine eigene Identität bräuchte man so ein Sammelsurium aus Attestierungen von verschiedensten Entitäten und möchte die jedenfalls auch so haben und nicht nur von einer. Ja, witzige Weise ist es so, dass diese Idee, insbesondere im Zuge dieser ganzen Blockchain Self Software Identity Systeme mittlerweile immer mehr Halt bekommt und immer mehr Attraktion ... ... mittlerweile gibt es schon Standards für sowas. Das heißt, sogar OpenID Connect unterstützt die sogenannten aggregated Claims beziehungsweise auch distributed Claims. Also im Endeffekt sagt OpenID Connect mittlerweile, wenn wir Identitätsattribute sozusagen über unser Protokoll wenn wir Identitätsattribute über unser Protokoll verteilen, dann kann man da Metadaten mitliefern, die die tatsächliche Autorität definiert für dieses Attribut. Also die tatsächliche konkrete Implementierung ist natürlich jetzt ein bisschen technisch. Aber was damit eigentlich wichtig ist, so die Standards Bemühungen, die es momentan gibt in W3C und OpenID Connect was jetzt nicht direkt ITF ist, sondern OpenID Connect Foundation aber eben eigentlich das wichtigste Identity Management Protokoll momentan. Die haben es schon, sozusagen realisiert, dass vielleicht ein Identitätsproviderdienst aber das ist ja noch lange nicht gesagt, dass dieser Identitätsproviderdienst tatsächlich die Autorität über die Attributsinformation ist. W3C geht sogar noch so weit in Verifiable Credentials, dass sie sagen naja, eigentlich ist es ja noch nicht mal notwendig, dass tatsächlich die Attribute übertragen werden. Also beispielsweise jetzt mein Geburtsdatum sondern eigentlich würde es erreichen, dass ich sozusagen nur übertrage, dass ich über 18 bin. Das sind sozusagen diese Privacy Credentials, die oft über Zero Knowledge Proofs laufen. W3C geht da sozusagen noch ein Stück weiter. Die sind aber auch teilweise kompatibel, diese zwei Standards. Was wir damit eben, oder der Vorteil insbesondere für ReclamID, den man jetzt hat, ist eigentlich ist es bei ReclamID ja so, dass der Nutzer alle seine Attribute selbst zertifiziert. Das heißt, der Nutzer sagt das ist mein Name, das ist meine Emailadresse. Das kannst du jetzt nehmen und akzeptieren aber eine Website hat keinen wirklichen Vertrauensanker. Also der weiß nicht genau, ist es jetzt tatsächlich die korrekte Emailadresse oder nicht, aber über diese Idee der verteilten Claims und der externen Autoritäten über bestimmte Identitätsattribute könnte man das eben sogar abbilden in einem Standardprotokoll. Momentan ist es nicht so, auch bei unserer Implementierung, aber wir sind da eben dran, das zu implementieren. Ja, wie benutzt man das eigentlich? Das ist so, ich sag's glaub ich heute noch dreimal, wir haben jetzt gleich ein Workshop, da kann man das gerne mal sich anschauen und ausprobieren. Aber eigentlich muss man nur zwei Sachen tun, um ReclamID nutzen zu können. Das erste ist, man installiert eine Web extension. Das ist jetzt das Beispiel für Firefox, die funktioniert auch unter Chrome, die funktioniert nicht unter Safari, weil da geht gar nichts mehr. Das ist der erste Teil, das ist relativ einfach. Der zweite Teil, man muss nur installieren. Jeder, der das schon mal probiert hat, weiß, dass man das Gesicht ungefähr dabei macht. Also es gibt eben wenig Pakete, es wird schon besser momentan, aber insbesondere aktuelle zu finden ist halt schwierig. Aber wir arbeiten daran, momentan auch Paketierung, damit das ein bisschen einfacher wird. Für Reclam, wir haben da auch eine Website, bieten wir momentan auch eben deshalb Docker-Images an, damit man einfach mal einen schnellen Docker starten kann, um es mal schnell auszuprobieren. Vielleicht mit einem vielleicht machen wir sogar mittelfristig, da komme ich noch kurz drauf, wir überlegen, ob wir nicht komplett genunert über M-Skripten in JavaScript kompilieren und das als Teil der Web extension mitliefern, dann wäre es sogar nur ein Schritt, um es zu haben. Aber soweit sind wir auch noch nicht, das ist noch ein bisschen so Arbeit. Also gleich ist ein Workshop, da kann man sich das mal anschauen und sich davon selber ein Bild machen, wie schwierig das ist, das zu benutzen. Ich denke eigentlich, dass es nicht so schwierig ist, momentan. Was hier noch zu sagen ist, es gibt auch schon, habe ich die hier? Ja, also man kann sich das auf Reclam Identity IO mal anschauen, was man alles tun muss, um es zu installieren auch. Es gibt auch schon Webseiten, wo man sich testweise einloggen kann, also einmal die offizielle Demo in Aufstrichen, das zweite ist eine Projekt-Website bei uns, wo wir es auch mal ausprobiert haben, ob man es sozusagen in Anstrichen produktiv nutzen kann. Die zwei Webseiten haben momentan sozusagen die Möglichkeit oder einen Knopf-Loggen mit Reclam. Die nächsten Schritte sind eben das Packaging für GNUnet, das ist eigentlich so momentan die größte Hürde denke ich auch so für den normalen Nutzer. Vielleicht eben, dass man das alles direkt ins Plug-in packt, wie gesagt, das ist ein bisschen so Kaffeesatzleserei, ob das so funktioniert, wie ich das gerne hätte. Und schließlich wollen wir sozusagen so ein offizielles 1.0 Release, abhängig natürlich vom Packaging und von dieser Browser-Plugging-ID bis Ende des Jahres noch raus bringen. Ja, das wäre mein Vortrag. Das ist eigentlich die Frage.