did:web erklärt
Jedes digitale Credential ist von jemandem signiert, und ein Verifier muss nachschlagen können, wer das ist und welche Schlüssel diese Stelle heute verwendet. did:web beantwortet das mit der Infrastruktur, die fast jede Organisation bereits hat: ihrem eigenen Domainnamen. Der Identifier sagt Ihnen, welche Domain Sie fragen müssen, die Antwort ist eine gewöhnliche Datei über HTTPS, und mehr muss nicht existieren, damit es funktioniert.
Was did:web genau ist
Eine DID ist ein dauerhafter Identifier, den jeder nachschlagen kann, um die öffentlichen Schlüssel dessen zu finden, der sie hält. Eine DID-Methode ist die Regel für dieses Nachschlagen, und es gibt Dutzende davon. Manche schreiben den Eintrag in eine Blockchain, manche in ein eigens gebautes Netzwerk, und jede zwingt einen Verifier, zu lernen, wie genau dieses System funktioniert.
did:web geht den umgekehrten Weg. Das Nachschlagen ist eine HTTPS-Anfrage an die im Identifier genannte Domain, und der Eintrag ist eine JSON-Datei, die der Domaininhaber veröffentlicht und bearbeitet wie jede andere Seite seiner Website. Es gibt kein Netzwerk, dem man beitreten muss, kein Ledger, in das geschrieben wird, und keine Gebühr.
Deshalb taucht es in fast jedem Projekt so früh auf. Ein Team, das eine Datei auf seinen Webserver legen kann, kann noch am selben Nachmittag Credentials ausstellen und prüfen, und der Identifier, der dabei entsteht, ist eine echte DID, die jede konforme Wallet und jeder konforme Verifier akzeptiert, kein Platzhalter, der später ersetzt werden muss.
Wie aus dem Identifier eine URL wird
Die Abbildung ist mechanisch, und genau das ist der Punkt. Eine blanke Domain führt zu einer Datei in dem well-known Verzeichnis, das Websites ohnehin für maschinenlesbare Metadaten nutzen. Hängen Sie nach der Domain durch Doppelpunkte getrennte Segmente an, werden daraus Pfadsegmente, sodass eine Organisation je Abteilung, je Umgebung oder je Ausstellungsdienst einen eigenen Identifier veröffentlichen kann, ohne etwas Neues zu registrieren.
Zwei Details werden leicht übersehen. Bei einer Portnummer muss der Doppelpunkt prozentkodiert werden, weil ein einfacher Doppelpunkt bereits die Teile des Identifiers trennt. Und die Datei muss über HTTPS mit einem gültigen Zertifikat ausgeliefert werden, denn der Transportweg ist das Einzige, was zwischen einem Verifier und einer gefälschten Antwort steht.
Der Identifier, den jemand Ihnen gibt
did:web:example.com:issuer:euDie HTTPS-URL, auf die er abgebildet wird, ohne Verzeichnisdienst dazwischen
https://example.com/issuer/eu/did.jsonDas DID document, das zurückkommt, mit den Schlüsseln und Endpunkten
{ "id": "did:web:example.com:issuer:eu", "verificationMethod": [ ... ] }
Warum Organisationen sich dafür entscheiden
Der erste Grund ist Wiedererkennbarkeit. Ein Verifier, der einen Identifier sieht, der auf eine Unternehmensdomain zeigt, kann auf die denkbar einfachste Weise prüfen, dass der Name auf dem Credential zum Namen auf der Website passt. Niemandem muss zuvor eine Registerabfrage oder eine Zertifikatskette erklärt werden, damit das ankommt.
Der zweite ist, dass der Betrieb nichts kostet. Das Dokument liegt hinter demselben Hosting, derselben Überwachung und demselben Änderungsprozess wie der Rest der Website. Es gibt kein separates System, das finanziert, verfügbar gehalten oder einem Prüfer erklärt werden müsste, und einen Schlüssel zu rotieren ist ein Deployment statt einer Transaktion.
Der dritte ist Übertragbarkeit. Weil jede Wallet- und Verifier-Bibliothek sie unterstützt, ist did:web die Methode, die mit einem Partner, mit dem Sie noch nie integriert haben, am ehesten funktioniert. Das macht sie zur natürlichen Wahl für Pilotprojekte, Testumgebungen und die Interoperabilitätsveranstaltungen, auf denen europäische Wallet-Implementierungen aufeinandertreffen.
Wo did:web aufhört
Alles, was die Methode Ihnen gibt, ruht auf der Domain. Wer die Registrierung, die Nameserver und das Zertifikat kontrolliert, kontrolliert den Identifier, also genügt eine versäumte Verlängerung, ein gekapertes DNS-Konto oder ein fälschlich ausgestelltes Zertifikat, um in Ihrem Namen zu sprechen. Darunter liegt keine zweite Signatur, auf die man zurückfallen könnte.
Es hat auch kein Gedächtnis. Ein Verifier sieht das Dokument so, wie es gerade ist, und kann nicht erfahren, was vergangene Woche darin stand, also ist ein ausgetauschter Schlüssel nicht von einem rotierten zu unterscheiden. did:webvh gibt es genau dafür: dasselbe Webhosting, dazu ein signiertes Protokoll jeder Änderung, an das nur angehängt werden kann, sodass ein Verifier die Historie vom ersten Eintrag bis zum aktuellen Stand verfolgen kann.
Und es ist keine Identitätsprüfung. Ein Dokument unter einer Domain zu veröffentlichen, beweist Kontrolle über diese Domain und sonst nichts. Wenn ein Verifier wissen muss, dass eine juristische Person die ist, für die sie sich ausgibt, kommt diese Sicherheit aus einer Trusted List, einem qualifizierten Zertifikat oder einem dafür gebauten Trust Framework, während die DID-Methode nur die Schlüssel darunter trägt.
Was das für Sie bedeutet
Aussteller
Behandeln Sie das Dokument vom ersten Tag an als Produktionsinfrastruktur. Stellen Sie es unter Änderungskontrolle, überwachen Sie, dass die URL antwortet und das Zertifikat gültig ist, und lassen Sie einen ausgemusterten Schlüssel zur Prüfung eingetragen, solange noch irgendetwas im Einsatz ist, das damit signiert wurde.
Vertrauende Partei
Das Dokument abzurufen ist nicht dasselbe, wie ihm zu vertrauen. Entscheiden Sie getrennt, welche Domains Sie akzeptieren, weisen Sie alles zurück, dessen Zertifikat nicht validiert, und cachen Sie umsichtig: eine veraltete Kopie hält einen widerrufenen Schlüssel am Leben, eine fehlende reißt Ihren Dienst mit der Gegenseite zusammen in den Ausfall.
Wallet-Inhaber
Die Domain in einem Aussteller-Identifier ist einen Blick wert. Sie ist der eine Teil eines Credentials, den Sie ohne Werkzeuge lesen können, und ein Name, der nicht zu der erwarteten Organisation passt, ist ein Grund aufzuhören statt weiterzumachen.
Verwandte Begriffe
Häufig gestellte Fragen
Brauche ich spezielle Software, um einen did:web Identifier aufzulösen?
Nein. Der Identifier ist eine Bauanleitung für eine URL, und wer diese URL über HTTPS abruft, erhält das Dokument. Jeder HTTP-Client kann das, und deshalb ist did:web meist die erste Methode, die ein Team zum Laufen bringt. Eine allgemeine Resolver-Bibliothek lohnt sich im Produktivbetrieb trotzdem, weil sie die Kodierungsregeln und die Prüfungen am Dokument einheitlich anwendet, statt sie jedem Aufrufer zu überlassen.
Ist did:web weniger vertrauenswürdig, weil keine Blockchain beteiligt ist?
Es ist anders vertrauenswürdig. Eine Methode auf Basis eines Ledgers verteilt den Eintrag auf viele Parteien, damit keine einzelne ihn unbemerkt umschreiben kann. did:web legt diese Verantwortung beim Domaininhaber und bei den Zertifizierungsstellen hinter seinem TLS ab. Für eine Organisation, deren Name und Website ohnehin das sind, was Kunden wiedererkennen, ist das oft der ehrlichste Ort für dieses Vertrauen, solange allen klar ist, dass die Domain die Schwachstelle ist.
Was passiert mit bereits ausgestellten Credentials, wenn sich die Schlüssel ändern?
Ein Verifier ruft das Dokument in seinem aktuellen Stand ab, also verifiziert ein Credential nicht mehr, das mit einem inzwischen entfernten Schlüssel signiert wurde. Behalten Sie einen ausgemusterten Schlüssel im Dokument, so markiert, dass er noch verifizieren, aber nicht mehr signieren darf, mindestens so lange, wie die damit signierten Credentials gültig bleiben. Wenn ein Verifier belegen können muss, welcher Schlüssel an einem bestimmten Datum aktuell war, ist das der Punkt, an dem did:webvh seine zusätzliche Komplexität wert ist.
Quellen
Diese Seite dient der Information und stellt keine Rechtsberatung dar. Für verbindliche Vorgaben konsultieren Sie bitte direkt die W3C-Spezifikationen.