Zum Hauptinhalt springen

Von Passwörtern zu portablen Nachweisen: Ein Leitfaden für Entwickler zur Web3-Identität im Jahr 2025

· 10 Minuten Lesezeit
Dora Noda
Dora Noda
Software Engineer

Die meisten Apps verankern Identität immer noch an Benutzernamen, Passwörtern und zentralisierten Datenbanken. Dieses Modell ist fragil (Datenlecks), undicht (Datenweiterverkauf) und umständlich (endlose KYC-Wiederholungen). Der neue Stack, der sich um dezentrale Identifikatoren (DIDs), verifizierbare Nachweise (VCs) und Attestierungen bildet, weist auf eine andere Zukunft hin: Benutzer tragen kryptografische Nachweise von Fakten über sich selbst und geben nur das preis, was benötigt wird – nicht mehr und nicht weniger.

Dieser Beitrag fasst die aktuelle Lage zusammen und bietet einen praktischen Bauplan, den Sie noch heute umsetzen können.

Der Wandel: Von Konten zu Nachweisen​

Der Kern dieses neuen Identitäts-Stacks basiert auf zwei grundlegenden W3C-Standards, die die Art und Weise, wie wir Benutzerdaten handhaben, grundlegend verändern.

  • Dezentrale Identifikatoren (DIDs): Dies sind benutzergesteuerte Identifikatoren, die kein zentrales Register wie ein Domain Name System erfordern. Stellen Sie sich eine DID als eine permanente, selbstverwaltete Adresse für die Identität vor. Eine DID löst sich in ein signiertes „DID-Dokument“ auf, das öffentliche Schlüssel und Dienstendpunkte enthält und eine sichere, dezentrale Authentifizierung ermöglicht. Der v1.0-Standard wurde am 19. Juli 2022 zu einer offiziellen W3C-Empfehlung, was einen wichtigen Meilenstein für das Ökosystem darstellt.
  • Verifizierbare Nachweise (VCs): Dies ist ein manipulationssicheres, digitales Format zur Darstellung von Behauptungen, wie z. B. „Alter über 18“, „besitzt ein Diplom der Universität X“ oder „hat eine KYC-Prüfung bestanden“. Das VC Data Model 2.0 wurde am 15. Mai 2025 zu einer W3C-Empfehlung und legt damit eine moderne Grundlage für die Ausstellung und Verifizierung dieser Nachweise fest.

Was ändert sich für Entwickler? Die Veränderung ist tiefgreifend. Anstatt sensible persönlich identifizierbare Informationen (PII) in Ihrer Datenbank zu speichern, verifizieren Sie kryptografische Nachweise, die von der Wallet des Benutzers bereitgestellt werden. Sie können nur die spezifischen Informationen anfordern, die Sie benötigen (z. B. Wohnsitz in einem bestimmten Land), ohne das zugrunde liegende Dokument einzusehen, dank leistungsstarker Primitive wie der selektiven Offenlegung.

Wo es auf die Anmeldungen trifft, die Sie bereits verwenden​

Diese neue Welt erfordert kein Aufgeben vertrauter Anmeldeerlebnisse. Stattdessen ergänzt sie diese.

  • Passkeys / WebAuthn: Dies ist Ihre erste Wahl für eine Phishing-resistente Authentifizierung. Passkeys sind FIDO-Anmeldeinformationen, die an ein Gerät oder eine Biometrie (wie Face ID oder einen Fingerabdruck) gebunden sind und jetzt in allen wichtigen Browsern und Betriebssystemen weit verbreitet sind. Sie bieten ein nahtloses, passwortloses Anmeldeerlebnis für Ihre App oder Wallet.
  • Sign-In with Ethereum (SIWE / EIP-4361): Dieser Standard ermöglicht es einem Benutzer, die Kontrolle über eine Blockchain-Adresse nachzuweisen und diese mit einer Anwendungssitzung zu verknüpfen. Dies geschieht über eine einfache, signierte, Nonce-basierte Nachricht, die eine saubere Brücke zwischen traditionellen Web2-Sitzungen und der Web3-Kontrolle schlägt.

Die beste Vorgehensweise ist, sie zusammen zu verwenden: Implementieren Sie Passkeys für die alltägliche Anmeldung und bieten Sie SIWE für Wallet-verknüpfte Abläufe an, bei denen ein Benutzer eine krypto-native Aktion autorisieren muss.

Die Grundlagen für die Ausstellung und Überprüfung von Nachweisen​

Damit Nachweise nützlich sind, benötigen wir standardisierte Wege, um sie an Benutzer auszustellen und damit Benutzer sie Apps präsentieren können. Die OpenID Foundation stellt hierfür die beiden Schlüsselprotokolle bereit.

  • Ausstellung: OpenID for Verifiable Credential Issuance (OID4VCI) definiert eine OAuth-geschützte API, um Nachweise von Ausstellern (wie einer Regierungsbehörde oder einem KYC-Anbieter) in die digitale Wallet eines Benutzers zu übertragen. Es ist flexibel konzipiert und unterstützt mehrere Nachweisformate.
  • Präsentation: OpenID for Verifiable Presentations (OID4VP) standardisiert, wie Ihre Anwendung eine „Nachweisanfrage“ stellt und wie die Wallet eines Benutzers darauf reagiert. Dies kann über klassische OAuth-Weiterleitungen oder über moderne Browser-APIs geschehen.

Beim Entwickeln werden Sie auf einige wichtige Nachweisformate stoßen, die für verschiedene Ökosysteme und Anwendungsfälle konzipiert sind:

  • W3C VC mit Data Integrity Suites (JSON-LD): Oft gepaart mit BBS+-Kryptografie, um eine leistungsstarke selektive Offenlegung zu ermöglichen.
  • VC-JOSE-COSE und SD-JWT VC (IETF): Diese Formate sind für JWT- und CBOR-basierte Ökosysteme konzipiert und verfügen ebenfalls über starke selektive Offenlegungsfunktionen.

Glücklicherweise verbessert sich die Interoperabilität rapide. Profile wie OpenID4VC High Assurance tragen dazu bei, die technischen Optionen einzugrenzen, was die Integrationen zwischen verschiedenen Anbietern für Entwickler wesentlich einfacher macht.

DID-Methoden: Das richtige Adressschema wählen​

Eine DID ist lediglich ein Identifikator; eine „DID-Methode“ spezifiziert, wie sie an einer Vertrauenswurzel verankert ist. Sie sollten einige gängige Methoden unterstützen.

  • did:web: Diese Methode sichert eine DID mit einer von Ihnen kontrollierten Domain ab. Sie ist unglaublich einfach bereitzustellen und eine fantastische Wahl für Unternehmen, Aussteller und Organisationen, die ihre bestehende Web-Infrastruktur als Vertrauensanker nutzen möchten.
  • did:pkh: Diese Methode leitet eine DID direkt von einer Blockchain-Adresse ab (z. B. einer Ethereum-Adresse). Dies ist äußerst nützlich, wenn Ihre Benutzerbasis bereits Krypto-Wallets besitzt und Sie deren Identität mit On-Chain-Assets verknüpfen möchten.

Faustregel: Unterstützen Sie mindestens zwei Methoden – did:web für Organisationen und did:pkh für einzelne Benutzer. Verwenden Sie eine Standard-DID-Resolver-Bibliothek zur Abwicklung der Auflösung und konsultieren Sie offizielle Register, um die Sicherheit, Persistenz und Governance jeder neuen Methode zu bewerten, die Sie hinzufügen möchten.

Nützliche Bausteine, die Sie integrieren können​

Über die Kernstandards hinaus können verschiedene Tools Ihren Identitäts-Stack verbessern.

  • ENS (Ethereum Name Service): Bietet menschenlesbare Namen (ihrname.eth), die Blockchain-Adressen und DIDs zugeordnet werden können. Dies ist ein unschätzbares Werkzeug zur Verbesserung der Benutzerfreundlichkeit, zur Reduzierung von Fehlern und zur Bereitstellung einer einfachen Profilebene.
  • Attestierungen: Dies sind flexible, verifizierbare „Fakten über alles“, die On-Chain oder Off-Chain aufgezeichnet werden können. Der Ethereum Attestation Service (EAS) bietet beispielsweise eine robuste Grundlage für den Aufbau von Reputations- und Vertrauensgraphen, ohne jemals PII auf einem öffentlichen Ledger zu speichern.

Regulatorische Rückenwinde, die Sie verfolgen sollten​

Regulierung wird oft als Hürde angesehen, doch in diesem Bereich ist sie ein massiver Beschleuniger. Das EU Digital Identity Framework (eIDAS 2.0), offiziell als Verordnung EU 2024/1183 am 20. Mai 2024 verabschiedet, ist die bedeutendste Entwicklung. Es schreibt vor, dass alle EU-Mitgliedstaaten ihren Bürgern eine kostenlose EU Digital Identity Wallet (EUDI) anbieten müssen. Mit den am 7. Mai 2025 veröffentlichten Durchführungsbestimmungen ist dies ein starkes Signal für die Einführung von Wallet-basierten Nachweisen in öffentlichen und privaten Diensten in Europa.

Auch wenn Sie nicht in der EU tätig sind, erwarten Sie, dass die EUDI Wallet und ihre zugrunde liegenden Protokolle die Benutzererwartungen prägen und die Akzeptanz von Wallets weltweit vorantreiben werden.

Designmuster, die in der Produktion funktionieren (2025)​

  • Passwortlos zuerst, Wallets optional: Standardmäßig Passkeys für die Anmeldung verwenden. Es ist sicher, einfach und vertraut. Führen Sie SIWE nur ein, wenn Benutzer eine krypto-verknüpfte Aktion ausführen müssen, wie das Prägen eines NFT oder den Empfang einer Auszahlung.
  • Nachweise anfordern, nicht Dokumente: Ersetzen Sie umständliche Dokumenten-Uploads durch eine prägnante VC-Nachweisanfrage mittels OID4VP. Anstatt nach einem Führerschein zu fragen, fordern Sie einen Nachweis für „Alter über 18“ oder „Wohnsitzland ist X“ an. Akzeptieren Sie Nachweise, die selektive Offenlegung unterstützen, wie solche, die BBS+ oder SD-JWT verwenden.
  • PII nicht auf Ihren Servern speichern: Wenn ein Benutzer etwas nachweist, zeichnen Sie eine Attestierung oder ein kurzlebiges Verifizierungsergebnis auf, nicht den rohen Nachweis selbst. On-Chain-Attestierungen sind eine leistungsstarke Methode, um einen überprüfbaren Datensatz zu erstellen – „Benutzer Y hat KYC bei Aussteller Z am Datum D bestanden“ – ohne persönliche Daten zu speichern.
  • Organisationen als Aussteller mit did:web: Unternehmen, Universitäten und andere Organisationen kontrollieren bereits ihre Domains. Lassen Sie sie Nachweise als Aussteller mit did:web signieren, wodurch sie ihre kryptografischen Schlüssel unter ihren bestehenden Web-Governance-Modellen verwalten können.
  • ENS für Namen, nicht für Identität verwenden: Behandeln Sie ENS als benutzerfreundlichen Handle und Profilzeiger. Es ist großartig für die UX, aber bewahren Sie die maßgeblichen Identitätsansprüche innerhalb von Nachweisen und Attestierungen auf.

Eine Starter-Architektur​

Hier ist ein Bauplan für ein modernes, nachweisbasiertes Identitätssystem:

  • Authentifizierung
    • Standard-Login: Passkeys (FIDO/WebAuthn).
    • Krypto-verknüpfte Sitzungen: Sign-In with Ethereum (SIWE) für Wallet-basierte Aktionen.
  • Nachweise
    • Ausstellung: Integration mit OID4VCI-Endpunkten Ihrer gewählten Aussteller (z. B. einem KYC-Anbieter, einer Universität).
    • Präsentation: Lösen Sie OID4VP-Nachweisanfragen von Ihrer Web- oder nativen App aus. Seien Sie darauf vorbereitet, sowohl W3C VCs (mit BBS+) als auch SD-JWT VCs zu akzeptieren.
  • Auflösung & Vertrauen
    • DID-Resolver: Verwenden Sie eine Bibliothek, die mindestens did:web und did:pkh unterstützt. Pflegen Sie eine Positivliste vertrauenswürdiger Aussteller-DIDs, um Spoofing zu verhindern.
  • Attestierungen & Reputation
    • Dauerhafte Aufzeichnungen: Wenn Sie ein überprüfbares Signal einer Verifizierung benötigen, prägen Sie eine Attestierung, die einen Hash, die DID des Ausstellers und einen Zeitstempel enthält, anstatt den Anspruch selbst zu speichern.
  • Speicherung & Datenschutz
    • Minimalismus: Minimieren Sie drastisch die PII, die Sie serverseitig speichern. Verschlüsseln Sie alles im Ruhezustand und legen Sie strenge Time-to-Live (TTL)-Richtlinien fest. Bevorzugen Sie ephemere Nachweise und setzen Sie stark auf Zero-Knowledge oder selektive Offenlegung.

UX-Erkenntnisse​

  • Unsichtbar starten: Für die meisten Benutzer ist die beste Wallet die, über die sie nicht nachdenken müssen. Verwenden Sie Passkeys, um die Anmeldung nahtlos zu gestalten, und zeigen Sie Wallet-Interaktionen nur kontextbezogen an, wenn sie absolut notwendig sind.
  • Progressive Offenlegung: Fragen Sie nicht alles auf einmal ab. Fordern Sie den kleinstmöglichen Nachweis an, der das unmittelbare Ziel des Benutzers freischaltet. Mit selektiver Offenlegung benötigen Sie nicht das vollständige Dokument, um eine Tatsache zu verifizieren.
  • Schlüsselwiederherstellung ist wichtig: Ein an einen einzelnen Geräteschlüssel gebundener Nachweis ist eine Schwachstelle. Planen Sie von Anfang an die Neu-Ausstellung und geräteübergreifende Portabilität. Dies ist ein Hauptgrund, warum moderne Profile Formate wie SD-JWT VC und anspruchsbasierte Inhaberbindung übernehmen.
  • Menschenlesbare Handles helfen: Ein ENS-Name ist weitaus weniger einschüchternd als eine lange hexadezimale Adresse. Er reduziert Benutzerfehler und fügt eine Ebene erkennbaren Kontexts hinzu, auch wenn die wahre Autorität in den zugrunde liegenden Nachweisen liegt.

Was im nächsten Quartal zu liefern ist: Eine pragmatische Roadmap​

  • Wochen 1–2:
    • Fügen Sie Passkeys für Ihren primären Anmeldeablauf hinzu.
    • Sichern Sie alle krypto-nativen Aktionen hinter einer SIWE-Prüfung ab.
  • Wochen 3–6:
    • Pilotieren Sie eine einfache Alters- oder Regionssperre mittels einer OID4VP-Anfrage.
    • Akzeptieren Sie VC 2.0-Nachweise mit selektiver Offenlegung (BBS+ oder SD-JWT VC).
    • Beginnen Sie, Attestierungen für „Verifizierung bestanden“-Ereignisse zu erstellen, anstatt PII zu protokollieren.
  • Wochen 7–10:
    • Binden Sie einen Partneraussteller (z. B. Ihren KYC-Anbieter) über did:web ein und implementieren Sie eine DID-Positivliste.
    • Bieten Sie die Verknüpfung von ENS-Namen in Benutzerprofilen an, um die Adress-UX zu verbessern.
  • Wochen 11–12:
    • Führen Sie eine Bedrohungsmodellierung Ihrer Präsentations- und Widerrufsabläufe durch. Fügen Sie Telemetrie für gängige Fehlermodi hinzu (abgelaufener Nachweis, nicht vertrauenswürdiger Aussteller).
    • Veröffentlichen Sie eine klare Datenschutzhaltung, die genau erklärt, was Sie anfordern, warum, wie lange Sie es aufbewahren und wie Benutzer es überprüfen können.

Was sich schnell ändert (Behalten Sie dies im Auge)​

  • Rollouts der EU EUDI Wallet: Die Implementierung und Konformitätsprüfung dieser Wallets wird die Funktionen und die Verifizierungs-UX weltweit massiv prägen.
  • OpenID4VC-Profile: Die Interoperabilität zwischen Ausstellern, Wallets und Verifizierern verbessert sich dank neuer Profile und Testsuiten ständig.
  • Kryptosuites für selektive Offenlegung: Bibliotheken und Entwicklerleitfäden für BBS+ und SD-JWT VC reifen schnell heran, was ihre Implementierung erleichtert.

Prinzipien für die Entwicklung​

  • Nachweisen, nicht speichern: Standardmäßig Ansprüche verifizieren, anstatt rohe PII zu speichern.
  • Standardmäßig interoperabel: Unterstützen Sie von Anfang an mehrere Nachweisformate und DID-Methoden, um Ihren Stack zukunftssicher zu machen.
  • Minimieren & Offenlegen: Fordern Sie den kleinstmöglichen Anspruch an. Seien Sie transparent gegenüber Benutzern, was Sie überprüfen und warum.
  • Wiederherstellung langweilig gestalten: Planen Sie Geräteverlust und Ausstellerrotation ein. Vermeiden Sie spröde Schlüsselbindungen, die Benutzer stranden lassen.

Wenn Sie Fintech-, Social- oder Creator-Plattformen entwickeln, ist die nachweisbasierte Identität keine Zukunftswette mehr – sie ist der kürzeste Weg zu geringerem Risiko, reibungsloserem Onboarding und globaler Interoperabilität.

Share on Twitter