Zusammenfassung

  • Im W3C-Entwurf vom 1. Oktober gab es eine Konformitätsklasse für netzbasierte DID-URL-Dereferenzierer samt HTTP(S)-Beispielen. Die Fassungen vom 24. und 26. Oktober streichen diese Netzfunktion aus der Bindung.
  • Die HTTPS-Auflösung eines DID bleibt spezifiziert. Den Weg vom zurückgegebenen Dokument zur gemeinten Schlüsselstelle oder Ressource legt der Client zurück.

Der Server liefert ein DID-Dokument. Die Anwendung hatte aber did:example:123#key-1 bestellt. Wer jetzt „Auftrag erledigt“ auf den Karton stempelt, hat den Schlüssel im Karton übersehen.

Der W3C-Entwurf vom 1. Oktober beschrieb HTTP(S) sowohl für DID-Auflösung als auch für die Dereferenzierung einer DID-URL. Dazu gehörten Beispiele und eine eigene Konformitätsklasse für den netzbasierten Dereferenzierer. In der Fassung vom 24. Oktober entfielen diese Teile. Die Fassung vom 26. Oktober hält die Änderung fest; auch die OpenAPI-Beschreibung umfasst die Dereferenzierung nicht mehr.

Für die Auflösung bleibt der Netzwerkweg erhalten. Ein konformer Resolver muss laut aktuellem Text HTTPS-GET unterstützen, POST ist freiwillig. Er liefert das DID-Dokument und Metadaten. Damit können Anwendungen bei verschiedenen DID-Methoden eine gemeinsame Eingangstür nutzen.

Hinter dieser Tür beginnt eine andere Arbeit. Der Client muss dem Nutzer die Auswahl eines Resolvers je DID-Methode ermöglichen, das Ergebnis prüfen und den passenden Handler ausführen. Das Fragment behandelt er in den Beispielen selbst. Bei einer URL mit Service-Parameter kommt die Auswahl des Dienstes hinzu. Die Anwendung kennt den Verwendungskontext; der entfernte Resolver kennt ihn nur soweit, wie die Anfrage ihn preisgibt.

Die Trennlinie entstand aus einer konkreten Diskussion. In W3C-Issue 306 wurde im März die Frage aufgeworfen, wie ein entfernter Dereferenzierer ein Fragment behandeln sollte, dessen letzte Auswertung beim Client stattfindet. Das Protokoll vom 15. Oktober zeigt die weitere Debatte über abstrakte Algorithmen und feste Testschnittstellen. Ein Betreiber sollte deshalb zwei Nachweise verlangen: Was hat der Resolver geliefert? Was hat die Anwendung aus der vollständigen URL gemacht?

Die Dereferenzierung steht im Candidate-Recommendation-Entwurf weiterhin unter Änderungsvorbehalt. Für die gegenwärtige Architektur reicht eine grüne HTTP-Antwort als Nachweis der ersten Etappe. Für die letzte Etappe braucht es eine zweite Spur.