AktiviertTier AIdentität & Oracle

DID XLS-40

W3C-konforme dezentrale Identifikatoren werden im XRPL verankert. DID ist im XRP Ledger aktiviert. xrpscan nennt 30.10.2024 als Aktivierungsdatum und rippled 2.0.0 als erste Version.

Fachlich geprüft am 31.07.2026 · Autor: Philip F. Schmitt

Status: Aktiviert
XLS: XLS-40
Version: rippled 2.0.0
Aktiviert: 30.10.2024

Was ändert dieses Amendment?

Warum gibt es dieses Amendment?

Ein XRPL-Konto soll einen standardisierten dezentralen Identifikator veröffentlichen können, ohne dass eine zentrale Stelle diesen Identifikator kontrolliert.

Wie funktioniert der Mechanismus?

DIDSet erzeugt oder aktualisiert ein kontogebundenes DID-Objekt, DIDDelete entfernt es. Die XRPL-DID kombiniert die Netzwerkkennung mit der AccountID oder dem hexadezimalen Master Public Key. URI, Data und DIDDocument können auf ein externes Dokument verweisen oder kleine öffentliche Angaben direkt speichern.

Was ändert sich gegenüber dem Vorgänger?

Vorher	Nachher
Ein XRPL-Konto hatte keinen nativen, nach der W3C-DID-Methodik auflösbaren Identitätseintrag.	Das Konto kann einen persistenten DID-Anker veröffentlichen und mit seinem Schlüssel aktualisieren oder löschen.

Für wen ist die Änderung relevant?

XRP-Halter und Nutzer

Ein DID ist optional, bewegt keine XRP und bestätigt keine bürgerliche Identität. Veröffentlichte Angaben lassen sich von jedem lesen.

Wallets und App-Entwickler

Resolver und Wallets können den On-Ledger-Anker lesen, müssen das referenzierte DID-Dokument, Signaturen und externe Endpunkte trotzdem selbst prüfen.

Börsen und Emittenten

Institutionen können einen stabilen Identifikator mit Verifikationsmethoden oder Service-Endpunkten verknüpfen. Eine KYC-Aussage entsteht dadurch nicht automatisch.

Node-Betreiber

Nodes speichern ein reservepflichtiges DID-Objekt pro Konto und validieren Feldlängen, nicht jedoch den Inhalt externer Dokumente.

Welche Grenzen und Risiken bleiben?

Der Ledger prüft weder URI noch Data noch DIDDocument auf inhaltliche Gültigkeit oder W3C-Konformität.
Jedes der drei Datenfelder ist auf 256 Byte begrenzt.
DID-Inhalte und verlinkte öffentliche Dokumente dürfen keine sensiblen personenbezogenen Daten enthalten.
Ein DID beweist nicht, dass die behauptete reale Identität stimmt.
Die Sicherheit hängt vom Schlüsselmanagement des zugehörigen XRPL-Kontos und von der Verfügbarkeit externer Inhalte ab.

Welche Gebühren- und Performancewerte nennt die Spec?

Das DID-Objekt belegt eine Owner-Reserve des Kontos.

Technische Details: Transaktionen, Felder, Codes und Invarianten

Transaktionen

DIDSet
DIDDelete

Ledger-Objekte

Felder und Flags

DIDDocument (max. 256 Byte)
URI (max. 256 Byte)
Data (max. 256 Byte)

API-Methoden

account_objects
ledger_entry

Wie hängt dieses Amendment mit anderen zusammen?

Jede direkte Verbindung besitzt einen Typ, eine Erklärung und eine Primärquelle.

wird erweitert durch

Credentials

Credentials ergänzt die öffentliche DID-Verankerung um ausgestellte und vom Empfänger akzeptierte On-Ledger-Nachweise.

Beziehung in der Primärquelle prüfen ↗

wird korrigiert durch

fixEmptyDID

Leere DID-Ledger-Einträge werden abgewiesen. Die Korrektur betrifft DID.

Beziehung in der Primärquelle prüfen ↗

Wie geht es mit diesem Amendment weiter?

DID ist im XRP Ledger aktiviert. xrpscan nennt 30.10.2024 als Aktivierungsdatum und rippled 2.0.0 als erste Version.

Die Regeln sind bereits Teil des Mainnets. Serverbetreiber brauchen eine kompatible rippled-Version, normale Wallet-Nutzer müssen nichts manuell aktivieren.

Wo steht es in seiner Amendment-Familie?

Identität und Berechtigungen: Protokollfolge

DepositPreauthAktiviert · ab rippled 1.1.0
DIDAktiviert · ab rippled 2.0.0
fixEmptyDIDAktiviert · ab rippled 2.2.0
CredentialsAktiviert · ab rippled 2.3.0
PermissionedDomainsAktiviert · ab rippled 2.4.0
fixInvalidTxFlagsAktiviert · ab rippled 2.4.0
PermissionedDEXAktiviert · ab rippled 2.5.0

Welche Primärquellen belegen die Angaben?

← Alle XRPL-Amendments und XLS-Spezifikationen