Freigeben über

Häufig gestellte Fragen (FAQ)

  • Artikel

Diese Seite enthält häufig gestellte Fragen zu überprüfbaren Anmeldeinformationen und zur dezentralisierten Identität. Die Fragen sind in folgende Abschnitte unterteilt.

Grundlagen

Was ist ein DID?

Dezentrale Bezeichner (Decentralized Identifiers, DIDs) sind eindeutige Bezeichner, mit deren Hilfe der Zugriff auf Ressourcen gesichert, Anmeldeinformationen signiert und überprüft und der Austausch von Anwendungsdaten vereinfacht wird. Im Gegensatz zu herkömmlichen Benutzernamen und E-Mail-Adressen besitzen und steuern Entitäten die DIDs selbst (sei es eine Person, ein Gerät oder ein Unternehmen). DIDs bestehen unabhängig von externen Organisationen oder vertrauenswürdigen Mittelsmännern. Dies wird in der W3C-Spezifikation für dezentrale Bezeichner ausführlicher erläutert.

Warum benötigen wir einen DID?

Vertrauen im digitalen Raum setzt grundsätzlich voraus, dass Teilnehmer eigene Identitäten besitzen und steuern können, und diese Identität beginnt beim Bezeichner. In einer Zeit, in der Systeme und zentralisierte Identitäten täglich Ziel von groß angelegten Sicherheitsverstößen und Attacken sind, stellt die Dezentralisierung von Identitäten eine wichtige Sicherheitsanforderung für Verbraucher und Unternehmen dar. Personen mit eigenen, steuerbaren Identitäten können so überprüfbare Daten und Nachweise austauschen. Eine Umgebung mit dezentralen Anmeldeinformationen ermöglicht die Automatisierung vieler Geschäftsprozesse, die aktuell noch manuell und arbeitsintensiv ablaufen.

Was sind überprüfbare Anmeldeinformationen?

Ausweise und Nachweise gehören zu unserem Alltag: Anhand von Führerscheinen wird überprüft, ob wir ein Fahrzeug fahren dürfen. Universitätsabschlüsse belegen unseren Bildungsstand, und amtlich ausgestellte Pässe ermöglichen es uns, in andere Länder zu reisen. Überprüfbare Anmeldeinformationen ermöglichen es, diese Arten von Informationen Internet so einzusetzen, dass sie kryptografisch sicher sind, den Datenschutz gewährleisten und technisch überprüfbar sind. In der Spezifikation für W3C-Nachweise werden Nachweise ausführlicher erläutert.

Konzeptionelle Fragen

Was geschieht, wenn ein Benutzer sein Smartphone verliert? Können er seine Identität wiederherstellen?

Es gibt mehrere Möglichkeiten für Benutzer, ihre Identität wiederherzustellen, von denen jede gewisse Nachteile mit sich bringt. Microsoft evaluiert derzeit Optionen und entwirft Ansätze für die Wiederherstellung, die Benutzerfreundlichkeit und Sicherheit bieten und dabei Datenschutz und Selbstbestimmung der Benutzer*innen gewährleisten.

Wie weiß ein Benutzer, ob er einer Anfrage von einem Zertifikataussteller oder -verifizierer vertrauen kann? Woher weiß er, dass eine DID wirklich zu einem Unternehmen gehört?

Wir implementieren die „Well Known DID Configuration“-Spezifikation („Bekannte DID-Konfiguration“) der Decentralized Identity Foundation, um einen DID mit einem allgemein bekannten System (Domänennamen) zu verbinden. Jede DID, die mit der Microsoft Entra Verified ID-Instanz erstellt wurde, kann einen Stammdomänennamen enthalten, der im DID-Dokument codiert wird. Weitere Informationen über verknüpfte Domänen finden Sie im Artikel Verknüpfen Ihrer Domäne mit Ihrem verteilten Bezeichner.

Was sind die Größenbeschränkungen für einen überprüfbaren Nachweis in einer verifizierten ID?

  • Für eine Ausstellungsanforderung: 1 MB
  • Foto im Nachweis: 1 MB
  • Rückrufergebnis ohne Beleg: 10 MB

Welche Lizenzbedingungen gelten?

Es gibt keine speziellen Lizenzierungsanforderungen, um Nachweise auszugeben.

Wie setze ich den Microsoft Entra Verified ID-Dienst zurück?

Das Zurücksetzen setzt voraus, dass Sie sich vom Microsoft Entra Verified ID-Dienst abmelden und wieder anmelden. Ihre vorhandene Nachweiskonfiguration wird zurückgesetzt, und Ihr Mandant erhält einen neuen dezentralen Bezeichner (Decentralized Identifier, DID) zur Verwendung bei der Ausstellung und Präsentation von Nachweisen.

  1. Befolgen Sie die Anweisungen zum Abmelden.
  2. Führen Sie die Bereitstellungsschritte von Microsoft Entra Verified ID aus, um den Dienst neu zu konfigurieren.
    1. Wenn Sie Verified ID manuell einrichten, wählen Sie für Ihre Azure Key Vault-Instanz einen Speicherort in derselben oder der nächstgelegenen Region aus. Durch Auswählen derselben Region werden Probleme im Bezug auf die Leistung und Wartezeit vermieden.
  3. Schließen Sie die Einrichtung Ihres Nachweisdiensts ab. Sie müssen Ihre Anmeldeinformationen neu erstellen.
    1. Sie müssen auch neue Anmeldeinformationen ausstellen, da Ihr Mandant nun über einen neuen DID verfügt.

Wie kann ich die Region meines Microsoft Entra-Mandanten überprüfen?

  1. Navigieren Sie im Azure-Portal zu Microsoft Entra ID, um das Abonnement aufzurufen, das Sie für Ihre Microsoft Entra Verified ID-Bereitstellung verwenden.

  2. Wählen Sie unter Verwalten die Option Eigenschaften aus.

    Screenshot der Einstellungen zum Löschen und Deaktivieren.

  3. Sehen Sie sich den Wert für „Land“ oder „Region“ an. Wenn es sich bei dem Wert um ein Land oder eine Region in Europa handelt, wird Ihr Microsoft Entra Verified ID-Dienst in Europa eingerichtet.

Unterstützt Microsoft Entra Verified ID ION als DID-Methode?

Verified ID unterstützte die Methode „DID:ION“ in der Vorschau bis Dezember 2023. Anschließend wurde sie eingestellt.

Wie wechsle ich von „did:web“ zu „did:ion“?

Wenn Sie von did:ion zu did:web wechseln möchten, können Sie die folgenden Schritte über die Admin-API ausführen. Zum Ändern der Autorität müssen alle Anmeldeinformationen neu ausgestellt werden:

Exportieren der vorhandenen „did:ion“-Anmeldeinformationsdefinitionen

  1. Verwenden Sie für die did:ion-Autorität das Portal, um alle Anzeige- und Regeldefinitionen der vorhandenen Anmeldeinformationen zu kopieren.
  2. Wenn Sie über mehrere Autoritäten verfügen und die did:ion-Autorität nicht die Standardautorität ist, müssen Sie die Admin-APIs verwenden. Stellen Sie im Verified ID-Mandanten mithilfe der Admin-API eine Verbindung her, und listen Sie die Autoritäten auf, um die Autoritäts-ID für die did:ion-Autorität abzurufen. Verwenden Sie dann die API zum Auflisten von Verträgen, um die Verträge zu exportieren, und speichern Sie das Ergebnis in einer Datei, damit Sie die Verträge neu erstellen können.

Erstellen der neuen „did:web“-Autorität

  1. Erstellen Sie mithilfe der Onboarding-API die neue did:web-Autorität. Wenn Ihr Mandant nur über eine „did:ion“-Autorität verfügt, können Sie alternativ den Dienst deaktivieren und anschließend aktivieren, um mit Verified ID-Konfigurationen neu zu starten. In diesem Fall können Sie zwischen den Setupoptionen Schnell und Manuell wählen.
  2. Wenn Sie eine Autorität vom Typ „did:web“ mithilfe der Admin-API einrichten, müssen Sie DID-Dokument generieren aufrufen, um Ihr DID-Dokument zu generieren, dann Bekanntes Dokument generieren aufrufen und anschließend JSON-Dateien in den entsprechenden bekannten Pfad hochladen.

Neuerstellen von Anmeldeinformationsdefinitionen

Nachdem Sie Ihre neue did:web-Autorität erstellt haben, müssen Sie Ihre Anmeldeinformationsdefinitionen neu erstellen. Wenn Sie den Dienst deaktiviert und ein erneutes Onboarding durchgeführt haben, können Sie dazu das Portal verwenden. Andernfalls müssen Sie die API zum Erstellen von Verträgen verwenden, um die Verträge neu zu erstellen.

Aktualisieren vorhandener Anwendungen

  1. Aktualisieren Sie alle vorhandenen Anwendungen (Aussteller-/Überprüfungs-Apps), um die neue did:web authority zu verwenden. Aktualisieren Sie für Aussteller-Apps auch die URL des Anmeldeinformationsmanifests.
  2. Testen Sie die Ausstellungs- und Überprüfungsflows von der neuen „did:web“-Autorität. Sobald die Tests erfolgreich sind, fahren Sie mit dem nächsten Schritt fort, um die „did:ion“-Autorität zu löschen.

Löschen der „did:ion“-Autorität

Wenn Sie den Dienst nicht deaktiviert und kein erneutes Onboarding durchgeführt haben, müssen Sie Ihre alte did:ion-Autorität entfernen. Verwenden Sie die API zum Löschen von Autoritäten, um die „did:ion“-Autorität zu löschen.

Ja, nach der Neukonfiguration des Diensts verfügt Ihr Mandant über einen neuen DID, der zum Ausstellen und Überprüfen von Nachweisen verwendet wird. Sie müssen Ihren neuen DID Ihrer Domäne zuordnen.

Ist es möglich, die Abfrage von „alten DIDs“ durch Microsoft anzufordern?

Nein. Zu diesem Zeitpunkt ist es nicht möglich, den DID Ihres Mandanten beizubehalten, nachdem Sie sich von dem Dienst abgemeldet haben.

Ich kann ngrok nicht verwenden. Was muss ich tun?

Die Tutorials zum Bereitstellen und Ausführen der Beispiele beschreiben die Verwendung des ngrok Tools als Anwendungsproxy. Dieses Tool wird manchmal von IT-Administratoren blockiert, und kann in Unternehmensnetzwerken nicht mehr verwendet werden. Eine Alternative besteht darin, das Beispiel in Azure App Service bereitzustellen und es in der Cloud auszuführen. Die folgenden Links helfen Ihnen bei der Bereitstellung des jeweiligen Beispiels in Azure App Service. Der Tarif „Kostenlos“ reicht zum Hosten des Beispiels aus. Für jedes Tutorial müssen Sie zunächst die Azure App Service-Instanz erstellen, dann die Erstellung der App überspringen (da Sie bereits über eine App verfügen) und das Tutorial anschließend mit der Bereitstellung fortsetzen.

Unabhängig davon, welche Sprache Sie für das Beispiel verwenden, wird der Azure AppService-Hostname https://something.azurewebsites.net als öffentlicher Endpunkt verwendet. Sie müssen nichts zusätzlich konfigurieren, damit es funktioniert. Wenn Sie Änderungen am Code oder an der Konfiguration vornehmen, müssen Sie das Beispiel erneut in Azure AppServices bereitstellen. Die Problembehandlung/das Debuggen ist nicht so einfach wie bei der Ausführung des Beispiels auf Ihrem lokalen Computer, auf dem Fehler in Ablaufverfolgungen im Konsolenfenster angezeigt werden. Mit dem Protokolldatenstrom können Sie jedoch vergleichbare Ergebnisse erzielen.

Netzwerkhärtung für Rückrufereignisse

Die Anforderungsdienst-API verwendet Rückrufe zu einer URL, die von der Anwendung der vertrauenden Seite bereitgestellt wird. Diese URL muss über das Verified ID-System erreichbar sein, damit die Rückrufe empfangen werden. Rückrufe stammen aus der Azure-Infrastruktur in derselben Region wie Ihr Microsoft Entra-Mandant. Wenn Sie Ihr Netzwerk härten müssen, haben Sie dafür zwei Möglichkeiten.

  • Verwenden Sie die Azure Firewall-Diensttags von AzureCloud.
  • Verwenden Sie den veröffentlichten CIDR-Bereich, um Ihre Firewall zu konfigurieren. Sie müssen AzureCloud.regions verwenden, die dem Ort entsprechen, an dem Ihr Microsoft Entra-Mandant bereitgestellt wird, um Ihre Firewall so zu konfigurieren, dass Rückrufdatenverkehr von der Anforderungsdienst-API durchgelassen wird. Wenn Sich Ihr Mandant beispielsweise in der EU befindet, sollten Sie alle CIDR-Bereiche aus AzureCloud.northeurope, AzureCloud..westeurope usw. für die Konfiguration Ihrer Firewalls auswählen.

Scannen des QR-Codes

In der Dokumentation bezieht sich die scan the QR code-Anweisung sofern nicht anders angegeben auf das Scannen mit der mobilen Microsoft Authenticator-App. Es ist möglich, den QR-Code mithilfe der Kamera-App des Smartphones zu scannen, die dann den Microsoft Authenticator startet. Damit dies funktioniert, muss der Protokollhandler für openid-vc:// für Microsoft Authenticator registriert sein. Wenn dafür eine andere mobile App registriert wurde, wird der Authenticator nicht geöffnet. Bei einigen älteren mobilen Android-Versionen funktioniert das Scannen des QR-Codes mit der Kamera-App nicht, und es gibt keine andere Problemumgehung als die Verwendung der Microsoft Authenticator-App zum Scannen.

Nächste Schritte