Zusammenfassung

  • Die geltende DID-Charta von 2024 hat DID Resolution als Arbeitsergebnis auf dem Recommendation Track aufgenommen und wurde bis 28. Oktober 2026 verlängert. Die Arbeiten im August haben somit eine bestehende institutionelle Grundlage.
  • Am 6. August erschien ein Candidate Recommendation Snapshot. Dieser Patent Review Draft eröffnete bis 5. Oktober eine Ausschlussmöglichkeit und formulierte Implementierungskriterien je Funktion; er ist weder eine W3C Recommendation noch eine Billigung der Technik.
  • Am 10. August begann die Verfeinerung einer Fortsetzungscharta. Der öffentliche Entwurf, einschließlich des am 27. August zusammengeführten Repository-Stands, führt DID Resolution dennoch als Working Draft, nennt den 10. Juli als jüngste Veröffentlichung und verweist auf den alten Exclusion Draft von 2024.
  • Die offizielle Publikationshistorie enthält inzwischen außerdem einen Candidate Recommendation Draft vom 28. August. Er ist der jüngste integrierte Arbeitstext, übernimmt aber nicht automatisch die Patentfunktion des Snapshots vom 6. August.
  • Vor der Advisory-Committee-Prüfung sollte ein schmales Übergabeprotokoll die geltende Charta, den jüngsten lesbaren Entwurf, den maßgeblichen Snapshot, das Ausschlussfenster, gefährdete Funktionen und datierte Implementierungsbelege verbinden. Das ist Nachweisführung, keine zusätzliche Entscheidungshürde.

Kontinuität ist kein Copy-and-paste-Vorgang

Die Strategy-Issue zur neuen Charta sagt ausdrücklich, dass keine wesentlichen Änderungen vorgesehen sind. Die bestehende Working Group brauche schlicht mehr Zeit, weil die Konsensbildung zu DID Resolution länger gedauert habe als erwartet.

Das ist plausibel. Es macht die Übergabe aber nicht trivial.

Wer nur die Bezeichnung des Arbeitsergebnisses von einer Charta in die nächste kopiert, übernimmt einen Namen, nicht zwingend seinen Verfahrenszustand. Bei DID Resolution beantwortet jede offizielle Oberfläche eine andere Frage. Die Publikationshistorie sagt, welcher Text zuletzt erschien. Die IPR-Seite sagt, welcher stabile Text ein Ausschlussfenster ausgelöst hat. Der Testbericht zeigt eine konkrete Ausführung. Die Gruppenseite sagt, welche Charta derzeit gilt.

Das Wort „aktuell“ reicht dafür nicht. Der aktuellste Text ist nicht automatisch der aktuelle Patentbezug. Der sichtbare Testlauf ist nicht automatisch ein Nachweis für den neuesten Text. Die vorgeschlagene Charta ist nicht automatisch der gegenwärtige Auftrag.

Kontinuität verlangt deshalb eine relationale Antwort: Was wird übergeben, unter welcher Befugnis entstand es, welcher Text kontrolliert welchen Verfahrensschritt und welche offenen Nachweise reisen mit?

Die bestehende Charta trägt die Candidate-Recommendation-Arbeit

Die im April 2024 genehmigte Charta nahm DID Resolution als neues Ergebnis auf dem Recommendation Track auf. Ursprünglich sollte die Gruppe im April 2026 enden; die Laufzeit wurde bis zum 28. Oktober verlängert. Auf der W3C-Gruppenseite ist diese Frist als gegenwärtiger Stand ausgewiesen.

Damit lässt sich eine wichtige Grenze ziehen. Die August-Veröffentlichungen brauchen keine rückwirkende Legitimation durch die künftige Charta. Sie wurden unter einem laufenden Auftrag erarbeitet. Ebenso wenig ersetzt der öffentliche Chartaentwurf schon heute diesen Auftrag. Nach dem W3C Process liegen Genehmigung, Call for Participation und erneute Teilnahmeverpflichtungen noch vor ihm.

Die Strategy-Issue 562 beschreibt den Vorgang als Recharter einer bestehenden Gruppe und vermerkt „Substantive changes: None“. Der Grund ist zusätzlicher Zeitbedarf für DID Resolution.

Gerade ein solcher Fortsetzungsauftrag sollte die Anschlussstelle präzise ausweisen. Wurde der Patent-Snapshot unter der alten Charta veröffentlicht? Welche Ausschlussfrist läuft beim Übergang? Welche Funktion ist noch nicht stabil? Welcher Testlauf gehört zu welcher Textfassung? Ohne diese Angaben kann dieselbe Deliverable-Zeile zwei institutionelle Perioden überspannen und dabei den Begründungszusammenhang verlieren.

Eine vorgeschlagene Charta schafft noch kein Mandat. Sie muss, falls sie genehmigt wird, den bereits autorisierten Arbeitsstand korrekt entgegennehmen.

Der Snapshot friert einen Bezugspunkt ein, der Draft nicht

Candidate Recommendation Snapshot und Candidate Recommendation Draft klingen nach zwei Ausgaben derselben Sache. Im W3C-Verfahren erfüllen sie jedoch verschiedene Funktionen.

Der Snapshot vom 6. August ist ein stabiler Prüfpunkt. Der Process bezeichnet einen Candidate Recommendation Snapshot als Patent Review Draft. Mit seiner Veröffentlichung beginnt eine Ausschlussmöglichkeit. Folgerichtig nennt die IPR-Seite der DID Working Group den 6. August als Beginn und den 5. Oktober als Ende des laufenden Fensters.

Der Candidate Recommendation Draft vom 28. August ist dagegen ein fortgeschriebener Arbeitsstand. Seine Statusangabe erklärt, dass er beabsichtigte Änderungen seit der vorherigen Candidate Recommendation integriert, die später in einen weiteren Snapshot eingehen können. Er bleibt Work in Progress. Ein CR Draft löst nach dem Process nicht selbst eine Ausschlussmöglichkeit aus.

Ein belastbares Protokoll braucht daher mindestens diese getrennten Angaben:

  • jüngster integrierter technischer Text: CR Draft vom 28. August;
  • maßgeblicher Patent Review Draft: CR Snapshot vom 6. August;
  • laufendes Ausschlussfenster: 6. August bis 5. Oktober;
  • nächster stabiler Bezugspunkt: erst nach tatsächlicher Veröffentlichung eines weiteren Snapshots.

Wer ausschließlich dem jüngsten Datum folgt, verschiebt sonst den patentbezogenen Vergleichstext ohne den dazugehörigen Verfahrensakt. Wer ausschließlich den Snapshot liest, übersieht möglicherweise Änderungen, die Implementierer bereits prüfen sollen. Die Unterscheidung hält beide Lesarten korrekt.

Die Patentoberfläche ist weiter als der Chartaentwurf

In der DID-Resolution-Zeile des Chartaentwurfs steht noch der Working Draft vom 28. November 2024 als Exclusion Draft, samt der am 27. April 2025 abgelaufenen Periode. Für sich betrachtet ist diese Zeile veraltet.

Die spezialisierte IPR-Seite ist es nicht. Sie zeigt das neue Fenster vom 6. August bis 5. Oktober und bewahrt das Fenster 2024–2025 als Vorgeschichte. Der öffentliche Call for Exclusions stellt außerdem klar, dass die neue Gelegenheit auf Stoff beschränkt ist, der im früheren Referenztext nicht enthalten oder nicht erkennbar war.

Der Befund lautet damit Abgleich, nicht Versagen. Die verfügbaren Belege zeigen nicht, dass W3C die Ausschlussmöglichkeit vergessen oder den geltenden Bezug verborgen hätte. Vielmehr funktioniert die fachlich zuständige Oberfläche, während die Charta-Zeile vor der Genehmigung nachgeführt werden muss.

Auch ein offenes Ausschlussfenster ist kein Hinweis auf einen Patentstreit. Die IPR-Seite meldet keine bekannten Patentoffenlegungen zu den Spezifikationen der Gruppe. Eine Opportunity ist ein Verfahrenszustand, keine Behauptung über einen Anspruch.

Das Übergabeprotokoll sollte Snapshot, vorigen Referenztext, Beginn, Ende und die öffentliche IPR-Seite nennen. Es soll die juristische Fachakte verknüpfen, nicht in der Charta nacherzählen.

Implementierungsreife lässt sich nicht an Namen abzählen

Der August-Snapshot formuliert anspruchsvolle Exit Criteria. Für jede Funktion werden mindestens zwei unabhängige, interoperable Implementierungen erwartet, geprüft durch offene Testsuiten. Maschinenprüfbare normative Aussagen brauchen je Funktion zwei konforme Implementierungen; nicht maschinenprüfbare Aussagen zwei Demonstrationen. Zudem sollen die Implementierungen mindestens zwei offen spezifizierte DID Methods unterstützen, die jeweils von mehr als einer Implementierung interoperabel umgesetzt werden.

Die Einheit der Prüfung ist also die Funktion, nicht die Zahl der Spalten im Bericht.

Der öffentliche Implementierungsbericht zeigt mehrere Implementierer und eine umfangreiche Matrix. Als Laufzeit ist der 27. März 2026 angegeben — mehrere Monate vor den beiden Candidate-Recommendation-Veröffentlichungen im August.

Das Datum beweist nicht, dass jedes Ergebnis unbrauchbar ist. Eine im März geprüfte Funktion kann unverändert geblieben sein. Umgekehrt beweist eine einzelne Failure- oder Not-implemented-Zelle nicht, dass die endgültigen Exit Criteria verfehlt sind. Textversion, Testversion, Funktionszuschnitt und Unabhängigkeit müssen zusammenpassen.

Ein nachvollziehbarer Beleg sollte daher aufführen:

  • die geprüfte Publikation oder den Spezifikations-Commit;
  • Test-Suite-Commit und Laufzeit;
  • normative Aussagen pro Funktion;
  • die zwei qualifizierten Implementierungen oder Demonstrationen;
  • die Grundlage für ihre Unabhängigkeit;
  • die offen spezifizierten DID Methods für die Interoperabilität;
  • ungelöste, übersprungene und gefährdete Punkte;
  • die Zuständigkeit für den nächsten Berichtslauf.

So begrenzt laufender Code die institutionelle Reifebezeichnung. Eine Charta kann Nachweise verlangen, aber keine Umsetzungstatsache herbeischreiben.

„At risk“ ist eine verwaltete Offenheit

Im Status des Snapshots vom 6. August wird DID URL dereferencing als Feature at Risk bezeichnet und als wahrscheinlich änderungs- oder entfernungsbedürftig beschrieben. Die Gruppe fragt Implementierer, ob die Funktion in der vorliegenden Definition einen Nutzen hat. Offene Issues der Klassen 1, 2 und 3 können den Text ebenfalls verändern.

Das ist kein Eingeständnis eines gescheiterten Verfahrens. Candidate Recommendation dient gerade dazu, Erfahrungen aus Implementierungen zu sammeln. Der Hinweis begrenzt, welche Stabilität Leser der Funktion zuschreiben dürfen.

Bei einer institutionellen Übergabe darf diese Begrenzung nicht verschwinden. Eine allgemeine Formulierung, die neue Gruppe werde DID Resolution „maintain“, sagt nicht, ob sie eine fertige Funktion, eine offene Frage, einen Entfernungskandidaten oder eine unvollständig geprüfte Behauptung erbt.

Das Protokoll soll den technischen Ausgang nicht vorwegnehmen. Es soll Funktionskennung, Issue, verlangten Nachweis, Entscheidungszuständigkeit und spätere Disposition verbinden. Dann bleibt die Sachentscheidung bei der Working Group, während der offene Zustand sichtbar bleibt.

Ein Entwurf darf abweichen — bis er genehmigt wird

Die öffentliche Charta bezeichnet sich als DRAFT. Anfangs- und Enddatum sind Platzhalter, was bei einem Vorschlag nachvollziehbar ist: Der Start hängt von einer späteren Genehmigung und einem Call for Participation ab. W3C kündigte eine Refinement-Phase ungefähr bis 15. September an.

Im W3C Process ist dies die Phase der breiten Prüfung, der formalen Behandlung von Issues und der Entscheidung, ob eine Advisory-Committee-Prüfung beginnt, die Verfeinerung verlängert oder der Vorschlag nicht weitergeführt wird.

Der Entwurf erklärt selbst, dass „Draft state“ den Zustand eines Ergebnisses bei Genehmigung der Charta meint; für den dynamischen Stand verweist er auf die Publikationsseite. Er muss also nicht stündlich synchron sein. Bei Genehmigung muss die Angabe aber stimmen.

Zum Recherchezeitpunkt führte der am 27. August zusammengeführte Stand weiterhin Working Draft, 10. Juli und den alten Exclusion Draft. Der Snapshot vom 6. August existierte da bereits seit drei Wochen; am 28. August kam der CR Draft hinzu.

Das ist eine korrigierbare Entwurfsdifferenz, kein Nichtigkeitsbeweis. Sie als Verfahrensbruch zu behandeln, würde den Sinn von Refinement verkennen. Sie ungeprüft durch die Genehmigung zu tragen, würde denselben Sinn verschenken.

Sechs Felder reichen für eine belastbare Übergabe

W3C verfügt bereits über spezialisierte Publikations-, IPR-, Gruppen- und Testseiten. Die Charta muss sie nicht duplizieren. Eine dünne gemeinsame Schicht kann ihre stabilen Kennungen verbinden:

  1. Befugnis: geltende Charta und Laufzeit, Commit des Nachfolgeentwurfs, Refinement-Stand und spätere Genehmigungsentscheidung.
  2. Text: jüngster integrierter Arbeitstext und maßgeblicher Snapshot in getrennten Feldern.
  3. Patentstatus: Patent Review Draft, Öffnung und Ende, vorheriger Referenztext und IPR-Link.
  4. Implementierung: geprüfte Fassung, Suite, Lauf, Funktionsabdeckung und Unabhängigkeitsgrundlage.
  5. Prüfung: At-risk-Funktion, offene Issues, horizontale und breite Reviews sowie Kommentarentscheidungen.
  6. Verantwortung: Eigentümer jedes Feldes, Korrekturweg und Ereignis, das den Zustand ablöst.

Ein neuer Zustand sollte als Übergang angefügt werden, nicht das institutionelle Gedächtnis überschreiben. Eine lesbare Tabelle und ein strukturiertes Register können dieselben IDs verwenden.

Die Verknüpfung mit dem weiteren Feld Identity and Access Management muss ebenfalls begrenzt bleiben. DID Resolution ist dafür relevant, doch W3C genehmigt damit weder sämtliche IAM-Produkte noch alle DID Methods oder rechtliche Identitätssysteme. Der Chartaentwurf schließt Authentifizierungs- und Autorisierungsprotokolle, Browser-APIs und den Anspruch, „Identity im Web zu lösen“, ausdrücklich aus.

Teilnahme liefert Sachkenntnis, Einspruch und Implementierungen. Sie verleiht keine Zuständigkeit über abwesende Betreiber oder Staaten. Das Protokoll soll diese Grenzen schärfen.

Quellen

  1. W3C — Ankündigung der öffentlichen Prüfung des DID Resolution v1 Candidate Recommendation Snapshot, 6. August 2026
  2. W3C — DID Resolution v1 Candidate Recommendation Snapshot, 6. August 2026
  3. W3C Patent Policy — Call for Exclusions zu DID Resolution v1, 6. August 2026
  4. W3C — IPR-Seite der DID Working Group
  5. W3C — Beginn des Refinement für den Entwurf einer DID-Working-Group-Charta, 10. August 2026
  6. W3C — Entwurf der Charta der Decentralized Identifier Working Group
  7. w3c/did-wg-charter — geprüfter Commit a840d21c6f8fac431ee1662d1bedb05940834623
  8. w3c/strategy — Issue 562 zur Charta der DID Working Group
  9. W3C — geltende Charta der DID Working Group, 25. April 2024
  10. W3C — Seite der DID Working Group
  11. W3C — Publikationshistorie von DID Resolution v1
  12. W3C — DID Resolution v1 Candidate Recommendation Draft, 28. August 2026
  13. W3C — Implementierungsbericht zu DID Resolution
  14. W3C Process Document, 18. August 2025