10. Mai’20
Übersetzung des IOTA Blogartikel.
Wir freuen uns, die Veröffentlichung der Beta-Version von IOTA Identity bekannt geben zu können. Dies markiert das Framework als “feature complete” auf dem Weg zu einer 1.0 Version. Es beinhaltet mehrere wichtige Meilensteine wie das Upgrade auf Chrysalis Phase 2, eine vereinfachte Higher-Level-API einschließlich Stronghold-Unterstützung und eine erste Implementierung der DID-Kommunikationsnachrichten, die auf dem Standard der Decentralized Identity Foundation (DIF) und der Arbeit von Hyperledger Aries basiert.
Dies baut auf der bestehenden Arbeit auf, die für die Alpha-Version gemacht wurde, in der wir die W3C-Standards für dezentrale Identifikatoren (DID) und verifizierbare Credentials implementiert haben. Wir haben diese Implementierung weiter verfeinert und unsere DID-Methode beim W3C eingereicht, um als eine der DID-Methoden-Spezifikationen gelistet zu werden.
IOTA Identity – Zusammenfassung
IOTA Identity ist ein Self Sovereign Identity (SSI) Framework, das es Menschen, Organisationen oder Maschinen ermöglicht, eine digitale Identität zu erstellen und die vollständige Kontrolle darüber zu haben – ohne die Erlaubnis eines Vermittlers oder einer zentralen Partei. Darüber hinaus gibt es die Kontrolle darüber, wie persönliche Daten geteilt und verwendet werden.
Social-Media-Plattformen wie Facebook und Linkedin zeigen uns jeden Tag, dass Online-Konten in hohem Maße auf von Nutzern bereitgestellte Inhalte angewiesen sind. Die auf diesen Plattformen bereitgestellten Informationen sind nicht vertrauenswürdig und können leicht gefälscht werden – das wollen wir mit unserer digitalen Identitätslösung verhindern.
An dieser Stelle kommen Verifiable Credentials (VCs) ins Spiel. Das sind digitale Aussagen über einen Identitätsaspekt wie “Name”, digital signiert von einer anderen Identität, die Autorität zu diesem Thema hat. Ein Beispiel: Mein Bachelor-Abschluss ist vertrauenswürdig, wenn eine Universität ihn unterschreibt, aber nicht so sehr, wenn er von Ihrer Mutter unterschrieben ist. Solche Aussagen machen Daten verlässlich und wertvoll. VCs ermöglichen es einer SSI-Lösung, nicht nur datenschutzfreundlicher zu sein, sondern auch mit Facebook- / LinkedIn-Profilen zu konkurrieren, da sie vertrauenswürdiger und genauer sind.
Wir wollen dieses Konzept noch einen Schritt weiterführen, indem wir es auf Geräte anwenden. Unzählige IoT-Geräte und Sensoren interagieren jeden Tag miteinander. Dadurch werden große Datenmengen generiert, aber bisher haben Programme nur selten Daten von Drittgeräten für die Entscheidungsfindung genutzt. Einer der Gründe dafür ist, dass die Herkunft der Daten und letztlich das Vertrauen in ein Gerät mit herkömmlicher Technologie nicht ausreichend bestimmt werden kann. IOTA Identity ermöglicht es IoT-Geräten, eigene Identitäten zu erstellen und verifizierbare Aussagen über sich selbst zu sammeln, wie z.B.:
- Der Hersteller des Geräts
- Die installierte Software und von wem
- Zertifikat der Kalibrierung
- Aussagen von anderen Identitäten, die die Daten verwendet und für korrekt befunden haben (Reviews)
Wir ermöglichen es IoT-Geräten, eine Reputation aufzubauen und vertrauenswürdig zu werden. Wir können dann die von den Geräten bereitgestellten Daten nutzen, um Entscheidungen zu treffen. Denken Sie an den Verkehrsfluss in einer Stadt:
Im Moment vertraut eine Stadt nur den Sensoren, die sie selbst aufgestellt hat, um den Verkehrsfluss zu bestimmen. Stellen Sie sich vor, wie viel mehr Informationen und damit eine höhere Präzision erreicht werden könnten, wenn die Autos sich selbst identifizieren und ihre generierten Daten teilen könnten. Dies wäre der Grundstein für eine vertrauenswürdige Datenwirtschaft, die durch IOTA Identity ermöglicht wird. Ohne eine Architektur, die die Schaffung von Vertrauen ermöglicht, könnte jeder Verkehrsdaten fälschen und in einem automatisierten Verkehrssystem, das sich auf externe Daten verlässt, Schaden anrichten. Vertrauenswürdige Identitäten sind daher die Grundlage für die Nutzung jeglicher Daten, die erzeugt werden. Jedes digitale System profitiert von Vertrauen, nicht nur Verkehrssysteme wie im obigen Beispiel.
Identitätskonto
Das erste große Feature, das wir mit dieser Beta-Version eingeführt haben, ist der Account, eine übergeordnete API zur Nutzung von IOTA Identity. Ähnlich wie beim letzten Chrysalis-Update wird die Nutzung von IOTA Identity durch die Verwendung des Accounts wesentlich einfacher. Es soll eine viel einfachere Schnittstelle bieten, die für 90%+ der Anwendungsfälle perfekt ist. Die anderen 10% sind komplexere Anwendungsfälle, die vielleicht immer noch die APIs auf niedrigerer Ebene nutzen wollen, um mehr Kontrolle über die Identitäten zu haben. Das Konto vereinfacht nicht nur die Interaktion mit DID-Dokumenten, sondern auch mit dem Tangle und Stronghold.
Identitätsnachrichten auf dem Tangle sind ziemlich kompliziert. Wir haben zwei Formate, um die DID-Auflösungszeiten zu optimieren, und sie müssen auf eine bestimmte Weise erstellt und verwendet werden. Beim Konto kümmert sich eine einzige Codezeile um die gesamte Nachrichtenformatierung und Veröffentlichung auf dem Tangle. Auch das Erstellen einer Identität ist ein recht komplizierter Prozess, da zunächst ein key-paar generiert werden muss, aus dem dann eine DID abgeleitet wird. Danach wird ein DID-Dokument erstellt, in das der public key eingebettet werden muss, und dieses muss auf dem Tangle veröffentlicht werden. Zum Schluss muss der private key sicher gespeichert und verwaltet werden. Das Konto erledigt all dies in einer einzigen Codezeile und speichert den private key in einem Stronghold oder einer anderen vom Entwickler definierten Speichermethode.
Derzeit ist das Account-Feature nur in Rust und noch nicht als Javascript-Bindung verfügbar, da dies einige größere Designverbesserungen im Projekt erfordert, die wir auf unserem Weg zu einer 1.0-Version in Angriff nehmen wollen.
DID-Kommunikation
Die andere wichtige Funktion, die wir implementiert haben, sind die DID-Kommunikationsnachrichten. Dies sind standardisierte Nachrichten, die zwei IOTA-Identitätsakteure einander senden, um irgendetwas in Bezug auf die Identität zu tun. Zum Beispiel können sie sich gegenseitig auffordern, die Kontrolle über ihre Identitäten zu beweisen, aber auch verifizierbare Credentials anzufordern, die sie teilen oder sogar signieren können. Die Verwendung dieser Nachrichten macht es nicht nur einfacher, IOTA Identity betriebene Anwendungen zu erstellen, sondern schafft auch unmittelbare Interoperabilität zwischen Anwendungen. So könnte eine IOTA-Identity-App eines Unternehmens mit einer App eines anderen Unternehmens interagieren.
Bisher haben wir unsere Version des genauen Nachrichtenlayouts definiert und ein grundlegendes Beispiel für die automatische Generierung und Beantwortung von DID Communications-Nachrichten in Rust erstellt. Das Konzept wird wiederholt und Javascript-Bindungen werden vor der Version 1.0 hinzugefügt.
Nächste Schritte
Wie bereits erwähnt, wird IOTA Identity weiter verfeinert und für ein 1.0-Release verbessert, wobei der Fokus auf Performance, Code-Qualität, Dokumentation und Javascript-Unterstützung liegt. Das kommende 1.0 Release wird einen sehr wichtigen Meilenstein für IOTA Identity markieren, da wir die Abwärtskompatibilität und den Versionswechsel von IOTA Identity in Zukunft unterstützen werden.
Während unsere Version 1.0 der nächste große Meilenstein ist, endet die Reise für IOTA Identity dort nicht. Wir haben viele Ideen für zusätzliche Funktionen für zukünftige Updates wie Datenschutzverbesserungen, Identitätsagenten, bieten aber auch mehr anwendungsfallspezifische Bibliotheken, damit IOTA Identity in den vielversprechenderen Anwendungsfällen einfach übernommen werden kann. In der Tat freuen wir uns sehr, bald mit der LINKS Foundation zusammenzuarbeiten, die eine Zero Knowledge Proof (ZKP) Spezifikation für IOTA Identity erstellt und damit die Datenschutzfunktionen von IOTA Identity massiv erhöht. Sie sind erfahrene Cybersecurity-Forscher, die eine Spezifikation erstellen werden, die auf etablierten wissenschaftlichen Literaturergebnissen basiert.
Während IOTA Identity noch nicht allgemein bekannt ist, nähern wir uns mit der Beta-Version einigen der populären SSI-Frameworks an und überholen sogar in Qualität und Funktionsumfang. Wir werden uns weiterhin darauf konzentrieren, ein erstaunliches Framework zu entwickeln, das sicher, performant aber auch einfach zu bedienen ist. Wenn Sie daran interessiert sind, mit IOTA Identity zu arbeiten, schauen Sie sich bitte unser Repository an und erwägen Sie, dem IOTA Identity X-Team beizutreten, wo sich gleichgesinnte Entwickler, Unternehmer und Studenten wöchentlich mit den IOTA Identity-Entwicklern treffen, um das Framework in einer entspannten und dennoch lehrreichen Atmosphäre zu diskutieren.
Um das Alpha-Release zu erreichen, wurde die IOTA Foundation durch eine vom EDF finanzierte Gruppe von Entwicklern unterstützt: Thoralf, Sebastian (huhn) und Tensor. Dieses Mal müssen wir Filancore, einem Startup aus der IOTA-Community, für ihre Unterstützung danken, die das Beta-Release ermöglicht hat. Während wir es wirklich genießen, mit Community-Mitgliedern zusammenzuarbeiten, freuen wir uns auch, das Team deutlich zu vergrößern, um das IOTA Identity-Framework, Entwickler-Tooling, Bindungen zu anderen Sprachen und Proof-of-Concepts mit eigener Manpower weiterzuentwickeln.
Vollständiges Changelog
Dies ist ein unvollständiges Changelog für die Änderungen zwischen Version 0.2 alpha und 0.3 beta.
Wesentliche Merkmale
- Account implementiert (#151)
- Implementierung von DID-Kommunikationsnachrichten und -umschlägen (#226)
- IOTA-Code so geändert, dass er nur in Chrysalis Phase 2-Netzwerken funktioniert (#161)
- Typen und Dateien umbenannt, um die Verwirrung zwischen agnostischer DID-Implementierung und did:ι Implementierung. Beigetragen von m-renaud! (#219, #233, #237, #243)
- Libjose-Implementierung hinzugefügt (#176)
Dokumentation / Spezifikation
- DID-Methoden-Spezifikation für die did:ι Methode hinzugefügt und beim W3C eingereicht (#207)
- Spezifikation für DID-Kommunikation hinzugefügt (#178, #186, #187, #202, #203)
- Viele Verbesserungen der Dokumentation (#174, #164, #171)
Kleinere Änderungen
- Geänderte kryptographische Suiten, um mit Stronghold zu arbeiten (#158)
- Verifiable Credential mit Credential-Typ zusammengeführt, um den Code zu vereinfachen (#170)
- Verifiable Presentation mit dem Presentation-Typ zusammengeführt, um den Code zu vereinfachen (#170)
- Ersetzt imμtab ≤ Eigenschaft aus DID-Dokument mit DID-URL-Abfrageparameter (#141)
- Service-Endpunkte besser zugänglich gemacht (#194)
- Benchmarking-Tests hinzugefügt (#223)
- Verbesserte Beispiele (#171, #251)