Erste Schritte mit IOTA Identity

04.06.2022

Übersetzung des Blogartikel von Autor Pascal Gottret – powered by Tangle Labs

Einführung

Nachdem Sie die ersten Artikel des Tangle Labs Blogs gelesen haben, sollten Sie nun eine gute Vorstellung davon haben, was SSI (Self-Sovereign Identity) ist, wie sie helfen kann, die Probleme der “Web2”-Welt zu lösen, und welche Anwendungsfälle SSI bieten kann. In diesem Artikel werden wir die technischen Details der Funktionsweise von SSI und ihrer Elemente erläutern. Wir werden auch erörtern, wie man mit Hilfe des IOTA Identity Protocol (ein von der IOTA Foundation entwickeltes Framework) mit der Technologie arbeiten kann.

Wie in der Einführung zu SSI beschrieben, geht es bei SSI darum, die Kontrolle über die Daten von einer zentralen Organisation und einem Verifizierer auf das Identitätssubjekt zu verlagern (d. h. eine Entität, eine Person, eine Organisation oder ein Objekt, für das die Identität erstellt wurde). Sie (das Subjekt) kann dann kontrollieren, wie ihre Daten weitergegeben und verwendet werden. Um diesen entscheidenden Schritt zum Schutz der Privatsphäre zu erreichen, müssen die grundlegenden Bausteine der SSI genau angewendet werden. Zu diesen Bausteinen gehören überprüfbare Datenregister (VDR), das Vertrauensdreieck (Aussteller, Inhaber und Überprüfer), digitale Geldbörsen und Agenten, dezentrale Identifikatoren (DIDs), überprüfbare Berechtigungsnachweise (VCs) und der Verwaltungsrahmen. Während das Vertrauensdreieck, die Geldbörsen und der Governance-Rahmen bereits in anderen Artikeln behandelt werden, konzentriert sich dieser Artikel auf die technische Erklärung und Anwendung des VDR, der DIDs und der VCs.

Erläuterung von VDR, DIDs und VCs

Das überprüfbare Datenregister und Einführung in die IOTA DLT

Für ein SSI-Ökosystem, in dem verschiedene Akteure miteinander kommunizieren, ist es von entscheidender Bedeutung, einen gemeinsamen öffentlichen Speicherort zu haben, um wichtige Informationen über Identitäten abrufen zu können. In der SSI-Sprache wird ein öffentlicher Speicher als verifizierbares Datenregister (VDR) bezeichnet.

Es gibt mehrere Möglichkeiten, ein VDR einzurichten. Sie können beispielsweise eine herkömmliche Datenbank aufbauen oder eine Implementierung der Distributed-Ledger-Technologie (DLT) wie eine Blockchain oder den IOTA Tangle verwenden. Letzteres bezieht sich auf ein:

"...verteiltes Netzwerk von Teilnehmern, die digitale Daten und Werte replizieren, teilen und synchronisieren, die über viele verschiedene Standorte verteilt sind. Anders als bei einer zentralisierten Datenbank gibt es keinen zentralen Administrator."
- Permissionless Innovation - Wie Sie Ihr Geschäft mit IOTA verbessern können, 2022

Eine der aufkommenden DLTs, obwohl keine klassische Blockchain, ist das IOTA-Protokoll. Es verwendet eine andere technische Grundlage, einen sogenannten gerichteten azyklischen Graphen (DAG), der die parallele Verarbeitung von Transaktionen ermöglicht. Sein Hauptziel ist es, ein allgemein nutzbares, skalierbares, interoperables und energieeffizientes Netzwerk bereitzustellen. Der Hauptunterschied zu klassischen Blockchain-Protokollen besteht darin, dass es keine Miner und damit keine Drittanbieter gibt, die Transaktionsgebühren erheben. IOTA ist ein sicheres, permissionless (erlaubnisfreies) Netzwerk, das es den Nutzern erlaubt, sowohl Daten als auch Werte zu übertragen. Im Zusammenhang mit SSI ermöglicht dies das Schreiben von Identitäten auf dem öffentlichen Ledger ohne Verwendung von Token.

Preukschat und Reed (2021) bewerteten die Möglichkeit des Einsatzes von DLT zur Verwirklichung von SSI wie folgt: DLT löst “ein Problem, für das es in der Geschichte der Kryptographie noch nie eine Lösung gab: wie eine global verteilte Datenbank als Wahrheitsquelle für öffentliche Schlüssel dienen kann, ohne einzelnen Fehlerpunkten oder Angriffen ausgesetzt zu sein.”

Die erlaubnisfreie, gebührenfreie und sichere Natur des IOTA-Protokolls eignet sich perfekt für einen VDR, um dezentralisierte Identifikatoren (DID) sicher und fälschungssicher im Ledger zu speichern, ohne sich auf eine zentrale vertrauenswürdige Autorität zu verlassen.

Decentralized identifiers (Dezentralisierte Identifikator)

Ein dezentraler Identifikator (DID) ist im Grunde eine neue Art eines weltweit eindeutigen Identifikators. Man kann ihn mit der URL vergleichen, die wir beim Surfen im Internet verwenden, z. B. https://tanglelabs.io. Jeder Akteur – Menschen, Organisationen, Dinge – im SSI-Ökosystem wird seine eigene DID haben. Diese DID ist eine Textzeichenfolge, die das Schema, die DID-Methode (die in den VDR aufgelöst wird, z. B. IOTA in unserem Beispiel unten) und eine eindeutige Zeichenfolge innerhalb dieser Methode enthält.

Abbildung 2 Beispiel für einen dezentralen Identifikator auf IOT

Ein DID enthält immer einen öffentlichen und einen privaten Schlüssel. Während der öffentliche Schlüssel einer DID, der Anmeldeinformationen signiert, auf dem VDR (d.h. dem IOTA DLT) gespeichert ist, wird der private Schlüssel in der Brieftasche des Inhabers aufbewahrt. Mit dieser Kombination ist der Inhaber – und nur der Inhaber – in der Lage, kryptographisch zu beweisen, dass er der Inhaber der DID ist. Der Identifikator ist fest an ihn gebunden.

Abbildung 3: ein Beispiel dafür, wie der DID den privaten und den öffentlichen Schlüssel kontrolliert

Bisher haben wir gelernt, dass die DID ein eindeutiger Identifikator ist, aber wie können andere Parteien diesen Identifikator verwenden, oder in SSI-Begriffen “auflösen”? Wie kann der Prüfer den öffentlichen Schlüssel des Ausstellers erhalten, um die Signatur des Ausstellers zu prüfen, und welchen Nachweis hat der Prüfer, dass der öffentliche Schlüssel dem Aussteller gehört?

Um dies zu erreichen, kontrolliert jede DID ein signiertes DID-Dokument und veröffentlicht es im VDR, um zu beweisen, dass die DID die Kontrolle über den öffentlichen Schlüssel hat. Hier schließt sich der Kreis zum VC: Der öffentliche Schlüssel ist fest an den Identifikator gebunden. Der Prüfer (der eine bestimmte Berechtigung prüft) löst das DID-Dokument des Ausstellers im VDR auf, erhält Informationen über den öffentlichen Schlüssel und die Prüfmethode und kann die Signatur in der VC kryptografisch prüfen.

did:iota:GYmbp6c5G77NhGSJJ5byNUj62nQEuGHAzQ2ikSGMr1jD{  "doc": {    "id": "did:iota:GYmbp6c5G77NhGSJJ5byNUj62nQEuGHAzQ2ikSGMr1jD",    "capabilityInvocation": [      {        "id": "did:iota:GYmbp6c5G77NhGSJJ5byNUj62nQEuGHAzQ2ikSGMr1jD#sign-0",        "controller": "did:iota:GYmbp6c5G77NhGSJJ5byNUj62nQEuGHAzQ2ikSGMr1jD",        "type": "Ed25519VerificationKey2018",        "publicKeyMultibase": "zAs84e72rbkhdCtAgLGsqEVSq3Kv7dYzjAwmhBRcdi6KS"      }    ]  },  "meta": {    "created": "2022-04-05T19:52:52Z",    "updated": "2022-04-05T19:52:52Z"  }}

Im Vergleich zu anderen eindeutigen Bezeichnern, wie z. B. DNS, zeichnen sich DIDs durch vier Haupteigenschaften aus, die sie von anderen unterscheiden:

• Eine DID ist ein dauerhafter Bezeichner
• Eine DID ist öffentlich auflösbar
• Eine DID ist kryptografisch verifizierbar (Nachweis der Kontrolle durch Kryptografie)
• Eine DID ist dezentralisiert (es ist kein zentrales Register erforderlich)

Man könnte fälschlicherweise meinen, dass DIDs die gleichen Funktionen wie herkömmliche Public Key Infrastructure (PKI)-Lösungen haben. Bei näherer Betrachtung werden Sie feststellen, dass die vier oben genannten Kernprinzipien in vollständig vertrauenswürdigen Umgebungen eine große Rolle spielen. Während herkömmliche PKI-Lösungen auf vertrauenswürdige Dritte (TTP) und zentrale Behörden (CA), wie X.509-Zertifikate, angewiesen sind, ist dies bei DIDs nicht der Fall. Um sicherzustellen, dass die Gegenseite vertrauenswürdig ist, lösen DIDs zwei Kernprobleme:

• Wie bindet man den Identifikator fest an den Verantwortlichen für die Identität?
• Wie bindet man den öffentlichen Schlüssel fest an den Bezeichner?

Mit anderen Worten: DID ermöglicht eine vertrauenswürdige Umgebung, ohne dass ein Dritter eingreifen muss.

Ein weiterer Vorteil von DID ist die Möglichkeit, den öffentlichen Schlüssel im DID-Dokument zu aktualisieren, indem die neue Version des DID-Dokuments (in den VDR) hochgeladen und mit dem früheren privaten Schlüssel signiert wird. Die Änderung öffentlicher Schlüssel ist eine starke Methode zur Erhöhung der Sicherheit, insbesondere im Falle von Datenverletzungen.

Verifiable credentials (VC)

Wie im Einführungsartikel erläutert, sind Berechtigungsnachweise eine Reihe von Aussagen über das DID-Subjekt des Berechtigungsnachweises und werden im Sinne der SSI in Form eines überprüfbaren Berechtigungsnachweises (VC) ausgestellt, der von seinem Aussteller kryptografisch signiert ist. Digitale Berechtigungsnachweise sollen Auskunft darüber geben, wer den Berechtigungsnachweis ausgestellt hat, ob er die vom Überprüfer benötigten Daten enthält, ob er manipuliert wurde und ob er noch gültig ist.

Derzeit gibt es im Wesentlichen vier Datenformate für verifizierbare Berechtigungsnachweise (VC):

• JSON-Web-Token (JWT)
• JSON-LD mit LD-Signaturen
• Zero Knowledge Proofs (ZKP) mit Camenisch-Lysyanskaya-Signaturen (ZKP-CL)
• JSON-LD ZKP mit BBS+-Signaturen

Jedes dieser Formate hat seine Vor- und Nachteile:

• Vereinfachung: Programmierung und Lesbarkeit.
• Selektive Offenlegung: Kann der Inhaber nur Teile einer VC nachweisen oder muss er die gesamte VC offenlegen?
• ZKP: Eine Methode, die in der Kryptographie verwendet wird, um zu beweisen, dass etwas bekannt ist, ohne die bekannten Informationen direkt offenzulegen. ZKPs sind indirekte Beweise, mit denen man beweisen kann, dass man ein Geheimnis kennt, ohne es jemals einer anderen Person zu offenbaren.
• Offenlegung der dauerhaften Kennung: Notwendigkeit, die Kennung des Inhabers (DID) anzugeben, um die Legitimität der ZKP zu beweisen.
• Semantische Disambiguierung: Ist die VC semantisch interpretierbar?

Characteristics	JSON Web Token (JWT)	JSON-LD	ZKP-CL	JSON-LD ZKP with BBS+
Simplicity	Simplest among all	Relatively simple	Most complicated among all	Complicated
Privacy Preserving	No	No	Yes	Yes
Selective Disclosure	No	No	Yes	Yes
Zero-Knowledge-Proof	No	No	Yes	Not yet
Need to reveal persistent identifier	Yes	Yes	No	No
Semantic Disambiguation	No	Yes	No	Yes

Die Wahrung der Privatsphäre ist das, was SSI erreichen will. VC-Formate mit ZKP-Unterstützung sind in der Lage, eine Reihe von Ansprüchen zu beweisen, ohne ihren tatsächlichen Inhalt offenzulegen. Jeder Anspruch erhält seine eigene kryptografische Signatur. Andererseits verbergen VC-Formate ohne Unterstützung von ZKP ihren Inhalt nicht, und die kryptografische Signatur signiert die vollständige VC.

Bedeutet dies, dass nur VC mit ZKP-Unterstützung verwendet werden sollten, da die anderen Formate die Privatsphäre nicht ausreichend unterstützen? Nein, nicht unbedingt. Es gibt Situationen, in denen rechtliche Rahmenbedingungen einen Prüfpfad der verwendeten Berechtigungsnachweise erfordern, wie z.B. im Finanzsektor mit “Know Your Customer”.

Derzeit unterstützt das IOTA Identity Protocol JSON-LD. ZKP-CL und JSON-LD mit BBS+-Signaturen werden derzeit erforscht und als Prototypen entwickelt.

Beispiel für einen Überprüfungsprozess

Schauen wir uns ein Beispiel an, wie das Verfahren zur Überprüfung eines Nachweises aussehen könnte. Stellen Sie sich vor, Sie bewerben sich um eine neue Wohnung und der Vermieter verlangt, dass der Mieter ein regelmäßiges Einkommen hat. Daher müssen Sie eine Arbeitsbescheinigung Ihres Arbeitgebers vorlegen. Bei SSI (DIDs und VCs) ist das Verfahren wie folgt:

1. Sie erstellen eine neue Identität (DID) in Ihrer digitalen Geldbörse (auf Ihrem Mobiltelefon) und speichern das DID-Dokument im IOTA-Ledger.
2. Sie stellen eine verschlüsselte Peer-to-Peer-Verbindung mit Ihrem Arbeitgeber her, der seinerseits seine eigene DID in einem öffentlichen Ledger gespeichert hat.
3. Der Arbeitgeber erstellt eine VC für Ihre DID (die angibt, dass Sie tatsächlich in diesem bestimmten Unternehmen arbeiten) und signiert sie mit ihrem privaten Schlüssel, und Ihre mobile Brieftasche speichert den Berechtigungsnachweis sicher darin.
4. Sie möchten die Berechtigungsnachweise dem Vermieter zeigen, der Ihre Berechtigungsnachweise prüft. Sie stellen zunächst eine verschlüsselte Peer-to-Peer-Verbindung mit ihm her. Anschließend erstellt Ihre mobile Brieftasche eine VP mit den erforderlichen Informationen. Die VP wird mit Ihrem privaten Schlüssel signiert und dem Prüfer vorgelegt.
5. Ihr Vermieter scannt den Berechtigungsnachweis. Seine mobile Brieftasche überprüft zunächst die Signatur des VP, um sicherzustellen, dass Sie der Inhaber der DID sind. Dann liest er die DID des Ausstellers (d. h. Ihres Arbeitgebers) und löst dessen DID-Dokument auf. Seine Brieftasche kann nun überprüfen, ob der Ausweis die erforderlichen Informationen enthält und ob die Signatur gültig ist, indem sie den öffentlichen Schlüssel des Ausstellers und die Überprüfungsmethode nachschlägt.
6. Da der Verifizierer einen Integritätsnachweis für den Berechtigungsnachweis hat, d. h. er kann sicher sein, dass der Berechtigungsnachweis echt ist, können Sie nun den Mietvertrag unterschreiben – und Sie sind der rechtmäßige Mieter der Wohnung. Es ist nicht nötig zu erwähnen, dass dies mit einer VC des Vermieters an Ihre mobile Geldbörse einhergeht!

Eine VC widerrufen

Ein Berechtigungsnachweis kann aus verschiedenen Gründen widerrufen werden: Die Berechtigungsnachweise können ablaufen, bestimmte VCs können irrtümlich ausgestellt worden sein oder aus jedem anderen Grund, den ein Aussteller für angemessen hält. Daher ist es notwendig, Funktionen in den SSI-Rahmen aufzunehmen, die es dem Prüfer ermöglichen, einen Widerruf zu verifizieren, ohne den Aussteller kontaktieren zu müssen.

Es gibt mehrere Möglichkeiten, dieses Ziel zu erreichen (kryptografische Akkumulatoren, Widerrufsliste, Berechtigungsstatus usw.). Eine Möglichkeit, eine VC zu widerrufen, besteht darin, die Verifizierungsmethode (öffentlicher Schlüssel) innerhalb des DID-Dokuments zu ändern. Wurde der öffentliche Schlüssel des Ausstellers geändert, kann die Prüfstelle die Signatur der VC nicht mehr prüfen, was der Prüfstelle anzeigt, dass die Berechtigung nicht mehr gültig ist.

Wie man IOTA-Identität nutzt

Nachdem Sie nun einen technischen Überblick darüber haben, wie VDR, DIDs und VCs miteinander verbunden sind, lassen Sie uns sehen, wie wir diese Technologie auf dem IOTA Distributed Ledger nutzen können. Dazu werden wir das IOTA-Identitätsprotokoll verwenden. Zuerst müssen wir alle Voraussetzungen auf unserem Computer installieren. Als nächstes erstellen wir unsere eigene Identität anhand von vorgefertigten Beispielen, lösen sie im IOTA-Ledger auf und führen ein Update durch. Schließlich können wir eine VC erstellen.

Vorbereitung

Um das IOTA-Identitäts-Framework zu verwenden, benötigen wir einen Rechner, der unter Windows, Linus oder MacOS läuft – der folgende Prozess wird unter der Annahme erklärt, dass wir mit einem Linux-Rechner arbeiten.

Das IOTA Identity Framework ist auf Github unter https://github.com/iotaledger/identity.rs (v. 0.5) verfügbar. Es gibt zwei Möglichkeiten, es zu installieren und zu verwenden: Entweder mit der Programmiersprache RUST oder mit den eingebauten WASM-Bindings, die es uns erlauben, alle Befehle in JavaScript auszuführen.

Im Repository ist ein verschlüsselter Speicher namens IOTA Stronghold enthalten. In der realen Welt ist eine sichere Schlüsselspeicherlösung wichtig, um die sichere Aufbewahrung Ihrer Schlüssel zu unterstützen. Sie können mehr über IOTA Stronghold hier erfahren https://blog.iota.org/iota-stronghold-6ce55d311d7c/. In diesem Leitfaden wollen wir die Möglichkeit bieten, die sichere Speicherung in unsere Beispiele einzubeziehen.

Bitte folgen Sie den Anweisungen, nachdem Sie sich mit Ihrem Rechner verbunden haben:

1. Falls noch nicht installiert, installieren Sie git:

sudo apt-get install git

2. Navigieren Sie zu dem Ordner, in dem Sie das IOTA-Identitäts-Repository installieren möchten. In unserem Fall verwenden wir

cd /var/lib/

3. Installieren Sie das IOTA Identity Framework

sudo git clone https://github.com/iotaledger/identity.rs

Für die RUST-Installation fahren Sie bitte hier fort. Für WASM springen Sie bitte zu Schritt 7.

4. Installieren Sie Rust und Cargo: führen Sie

sudo curl https://sh.rustup.rs -sSf | sh

Diese Installation kann einige Zeit in Anspruch nehmen. Weitere Informationen finden Sie unter https://www.rust-lang.org/tools/install.

5. Wechseln Sie in den Ordner identity.rs

cd identity.rs

6. Installieren Sie

cargo build

um alle Abhängigkeiten herunterzuladen, stellen Sie bitte sicher, dass Sie die notwendigen Berechtigungen haben; wenn Sie einen “permission denied”-Fehler erhalten, gehen Sie zurück zu /var/lib/ und führen Sie aus

sudo chmod 777 identity.rs

WASM-Bindung (JavaScript)

7. Vergessen Sie nicht, Ihre vorhandenen Pakete zu aktualisieren.

sudo apt-get update

8. In einigen Fällen werden Korrekturen benötigt.

sudo apt --fix-broken install

9. Installieren Sie Node.js und npm. Stellen Sie sicher, dass mindestens Version 16.0.0. installiert ist. Besuchen Sie https://github.com/nodesource/distributions/blob/master/README.md für weitere Anweisungen zur Aktualisierung von Node.js.

sudo apt install nodejssudo apt install npm

10. Installieren Sie die Bibliotheken für WASM und Stronghold.

npm install @iota/identity-wasmnpm install @iota/identity-stronghold-nodejs

11. Gehe in den Ordner bindings/wasm/

cd bindings/wasm/

12. Installieren Sie die notwendigen Abhängigkeiten.

/code

npm install

13. Erstellen Sie die Bindungen für node.js.

npm run build:nodejs

14. Ersetzen Sie im Ordner /examples/src

@iota/identity-wasm

imports durch

@iota/identity-wasm/node

für Node.js.

Sie sind nun bereit, mit dem IOTA Identity Framework zu arbeiten.

Erstellen einer DID (ohne sichere Speicherung des privaten Schlüssels)

Nachdem Sie nun alle Voraussetzungen installiert haben, können Sie Ihre eigene Identität erstellen.

Führen Sie in der Shell (RUST) aus:

cargo run --example create_did

oder (JavaScript):

npm run example:node -- create_did

Weitere Abhängigkeiten können erforderlich sein und werden automatisch heruntergeladen und kompiliert. Nach einer Weile sollten Sie Ihr DID-Dokument sehen. Die Ausgabe sieht wie das unten gezeigte Beispiel aus.

DID Document Transaction: https://explorer.iota.org/mainnet/message/d26cbf4e298a521e97eae1ecb195cf8fc43ed0d0eeb9763dcebea5c187e88d27Explore the DID Document: https://explorer.iota.org/mainnet/identity-resolver/did:iota:9zZZvvMaRXK2dKXxCi2BKnqCpBKE5hS8UK8eAZEKJQuiOk > {	key: {		type: 'ed25519',		public: '9a1Mmkqav6ePZMb1WdAxgBCNBdAZx1srXorhMBMhd9FE',		private: '...'		 },	doc: {		doc: {			id: 'did:iota:9zZZvvMaRXK2dKXxCi2BKnqCpBKE5hS8UK8eAZEKJQui',			capabilityInvocation: [Array]		 },	meta: {		created: '2022-04-05T20:24:02Z',		updated: '2022-04-05T20:24:02Z',	proof: [Object]		  }},receipt: {	network: 'main',	messageId: 	'd26cbf4e298a521e97eae1ecb195cf8fc43ed0d0eeb9763dcebea5c187e88d27',	networkId: 1454675179895816200,	nonce: 2236363	}}

Herzlichen Glückwunsch! Sie haben erfolgreich Ihre erste Identität erstellt.

Diese Aktion generiert Ihren öffentlichen und privaten Schlüssel.

DID erstellen (mit sicherer Speicherung des privaten Schlüssels)

Im Ordner

bindings/stronghold-nodejs

eine neue Datei erstellen:

create_did.js

und fügen Sie den folgenden Code ein (ersetzen Sie das Passwort):

const { AccountBuilder, ExplorerUrl } = require('@iota/identity-wasm/node')const { Stronghold } = require('@iota/identity-stronghold-nodejs')async function main() {	// Stronghold settings for the Account storage.	// This will load an existing Stronghold or create a new one 	automatically.	const filepath = "./example-strong.hodl";	const password = "my-password";	const stronghold = await Stronghold.build(filepath, password);	// This generates a new keypair stored securely in the above Stronghold,	// constructs a new DID Document, and publishes it to the IOTA Mainnet.	let builder = new AccountBuilder({	storage: stronghold,	});	let account = await builder.createIdentity();	// Print the DID of the newly created identity.	const did = account.did();	console.log(did.toString());	// Print the local state of the DID Document.	const document = account.document();	console.log(JSON.stringify(document, null, 2));	// Print the Explorer URL for the DID.	console.log(`Explorer URL:`, ExplorerUrl.mainnet().resolverUrl(did));}main()

Führen Sie nun das Kommando aus:

sudo node create_did.js

Ihre DID wird erstellt und der private Schlüssel wird sicher in der Datei

example-strong.hodl

gespeichert!

Auflösen einer DID

Um eine DID aufzulösen führe folgendes Kommando aus (RUST)

cargo run --example resolve

oder (JavaScript)

npm run example:node -- resolution

Bitte beachten Sie, dass in diesem Beispiel zunächst ein neues DID-Dokument erstellt wird, das dann aufgelöst wird. Um die gleiche DID zu verwenden, die Sie zuerst erstellt haben, bearbeiten Sie das obige Beispiel, um Ihre Schlüssel sicher zu speichern und sie abzurufen, um eine DID aufzulösen.

DID aktualisieren

Um eine DID zu aktualisieren, führen Sie aus (RUST)

cargo run --example manipulate_did

oder (JavaScript)

npm run example:node -- manipulate_did

Ändern Sie auch hier die Beispiele, um Ihren DID entsprechend wiederzuverwenden.

Ein VC erstellen

Dieses Beispiel enthält einen Nachweis über einen Universitätsabschluss im JSON-Format. Sie können es aber auch in jede andere Form von Berechtigungsnachweis ändern.

Um eine VC zu erstellen, führen Sie aus (RUST)

cargo run --example create_vc

oder (JavaScript)

npm run example:node -- create_vc

Ändern Sie auch hier die Beispiele, um Ihren DID entsprechend wiederzuverwenden.

Fazit

Als Demonstration der leicht zugänglichen Natur von Identität hat dieser Artikel aus technischer Sicht aufgezeigt, wie die Schlüsselelemente eines SSI-Ökosystems (VDR, VC und DID) unter Verwendung des IOTA-Identitätsprotokolls funktionieren und miteinander interagieren können. Dies verdeutlicht die Zugänglichkeit der offenen Technologie, die in nur wenigen, einfach zu befolgenden Schritten von jedermann und überall integriert und in seinen Entwicklungen verwendet werden kann. Diese Einfachheit und freie Nutzung von Open-Source-Lösungen wie IOTA Identity bietet eine solide Grundlage für eine allmähliche Marktreife hin zu einer breiteren Nutzung von SSI. Warum nicht einfach mal ausprobieren?

Quellen

Getting Started with IOTA Identity