Zusammenfassung

  • W3C Strategy Issue 563 eröffnete am 21. Juli 2026 die Neuchartierung der Web Real-Time Communications Working Group; nach dem Zieltermin 25. August bleibt sie offen und in der Verfeinerung.
  • Der Entwurf behauptet keine wesentliche Umfangsänderung, führt aber sechs Arbeiten als einzustellen auf und bezeichnet SFrame weiterhin als Ersatz für WebRTC Identity.
  • Die Sicherheitsprüfung verlangte einen Nachfolger für Identität, Ziel-Peer und Medienisolation oder eine ausdrückliche Einschränkung dieser Ziele.
  • Ein WebRTC-Co-Chair bestätigte, dass beide Technologien nicht austauschbar sind, nannte mangelndes Implementiererinteresse als Einstellungsgrund und verneinte ein Nachfolgeergebnis in der Gruppe.
  • Pull Request 869 ist offen und nicht zusammengeführt; er begrenzt die Überschneidung auf einzelne Anwendungsfälle. Eine Eigenschafts-Zuordnung sollte die nicht abgedeckten Reste festhalten.

Dokumentende und Eigenschaftsübergang sind zwei Vorgänge

Issue 563 beschreibt zunächst eine unspektakuläre Verlängerung. Seit dem 21. Juli erklärt der Eintrag, der Chartaentwurf ändere den Umfang nicht substanziell. Einige Entwürfe würden auslaufen, während reife Inhalte in weiter fortgeschrittene Recommendation-Track-Spezifikationen wanderten. Der Vorgang ist jedoch weiterhin offen, als „In Charter Refinement“ markiert und über den erwarteten Abschluss am 25. August hinaus nicht entschieden.

Damit ist die Beweislage eindeutig: Charta und Korrektur sind Entwürfe. Gerade dieser Zustand macht den Austausch wichtig. Eine missverständliche Nachfolgebehauptung kann korrigiert werden, bevor sie zum dauerhaften institutionellen Gedächtnis wird.

Sechs Einträge stehen unter Discontinued Work. Für vier normative Entwürfe nennt die Tabelle Migration oder Ersatz, zwei nicht normative Anwendungsfalldokumente gelten als ungewartet. Bei den normativen Texten bleiben Exclusion-Draft-Daten und Ursprungscharten sichtbar. Die Stilllegung ist also ein Publikations- und Patentstatus, nicht bloß eine Archivierungsentscheidung.

Identity und SFrame verteilen Vertrauen verschieden

Der aktuelle öffentliche Text sagt, SFrame in WebRTC-Erweiterungen solle WebRTC Identity ersetzen und Daten ebenso wie Audio und Video erfassen. Das ist mehr als die Feststellung geringer Nachfrage; es ist eine Funktionsbehauptung.

Die Candidate Recommendation von 2018 behandelt validierte Peer-Identität und eine vom Browser durchgesetzte Medienisolation. Medien sollten an einen identifizierten Ziel-Peer gebunden werden können und bei nicht erfüllten Identitäts- oder Isolationsbedingungen zurückgehalten werden. Die Quellen belegen keine breite Implementierung. Das ändert aber nicht die beschriebenen Eigenschaften.

RFC 9605 gibt SFrame eine andere Aufgabe: den Schutz codierter Medienframes in Mehrparteienkonferenzen. Die Schlüsselverwaltung liegt bei Anwendungen; die Sicherheitsbetrachtung sagt ausdrücklich, dass SFrame selbst keine senderbezogene Authentisierung der Mediendaten bietet. Das ist kein Fehler des Mechanismus, sondern eine andere Kontrollfläche.

Die Sicherheitsprüfung vom 24. August fragte deshalb, wo Identität, Ziel-Peer-Garantie und Medienisolation weitergeführt werden. Gibt es keinen Nachfolger, sollte die Charta das Ziel ausdrücklich enger fassen.

Der WebRTC-Co-Chair antwortete klar. SFrame und WebRTC Identity seien nicht als Ersatz verwandt. Identity werde wegen fehlenden Implementiererinteresses eingestellt. Für die genannten Eigenschaften gebe es innerhalb der Working Group kein Nachfolgeergebnis.

Ein offener Patch korrigiert die Begründung

Pull Request 869 wurde am 25. August eröffnet. Der vorgeschlagene Satz nennt fehlendes Interesse als Grund der Einstellung und sagt, SFrame in WebRTC Encoded Transform decke nur eine begrenzte Menge der in WebRTC Identity beschriebenen Anwendungsfälle ab.

Zum Stichtag war der Patch weder zusammengeführt noch in die öffentliche Charta übernommen. Deshalb lautet der Status „Korrektur vorgeschlagen“, nicht „Charta repariert“, „Entscheidung aufgehoben“ oder „SFrame verworfen“.

Selbst nach einer Zusammenführung bliebe „begrenzte Menge“ unbestimmt. Der Satz sagt noch nicht, welche Eigenschaften aufgegeben, vertagt, einer anderen Gruppe übergeben oder mangels Evidenz offen gelassen werden.

Discontinued beweist keine Gleichwertigkeit

Der W3C Process verlangt für unvollendete Recommendation-Track-Arbeiten, die nicht weitergeführt werden sollen, einen Discontinued Draft ohne substanzielle Änderung und mit Begründung. Innerhalb eines passenden Chartaumfangs kann die Arbeit später durch einen neuen Working Draft wiederaufgenommen werden.

Dieser Zustand warnt Leser vor ausbleibendem Fortschritt und bewahrt den Einstellungsgrund. Er beweist weder die Migration aller Eigenschaften noch Implementierung, Interoperabilität oder freiwillige Annahme eines angeblichen Ersatzes.

Heng Lus Disziplin einer minimalen Anfangsspezifikation liefert dafür eine schmale Regel: Der gemeinsame Datensatz trägt nur den notwendigen Koordinationszustand; spätere Implementierung und Annahme liefern die Beweise. Die Charta muss nicht jede ungenutzte Eigenschaft bewahren. Sie darf aber durch eine Bezeichnung keine Gleichwertigkeit erzeugen, die laufende Systeme nicht zeigen.

Eine Zuordnung für jede Eigenschaft

Für jede eingestellte Arbeit sollte ein kompakter Nachweis enthalten:

  • Quelldokument und exakten Publikationsstatus;
  • betroffene Sicherheits- oder Interoperabilitätseigenschaft;
  • vorhandene Implementierungsevidenz;
  • Disposition: migriert, ersetzt, aufgegeben, vertagt oder ohne Eigentümer;
  • Zielergebnis und zuständige Gruppe;
  • Gleichwertigkeitsprüfung und ungedeckten Rest;
  • Ausschluss- und Patentprüfungsverlauf;
  • Einwände und deren Behandlung; sowie
  • Auslöser für Neubewertung oder Wiederaufnahme.

Bei WebRTC Identity könnte der Datensatz eine begrenzte Überschneidung mit geschützten Medienanwendungen festhalten. Separat stünde, dass Peer-Identität, Zielbindung und browserseitige Isolation in der Working Group keinen benannten Nachfolger haben. Eine weitere Spalte enthielte mangelndes Interesse als Stilllegungsgrund.

So bleibt eine spätere lokale Entscheidung möglich. Wenn Anwendungen erneut Bedarf für zielgebundene Identität zeigen, ist die zurückgelassene Eigenschaft auffindbar, ohne dass die gesamte Candidate Recommendation wiederkehren muss. Bleibt die Nachfrage aus, ist die Stilllegung weiterhin nachvollziehbar.

Was die Akten nicht belegen

Die öffentlichen Quellen belegen keine breite Umsetzung von WebRTC Identity, keine Entfernung einer verbreiteten Browserfunktion, keinen SFrame-Mangel und keinen Patentverstoß. Sie belegen weder eine genehmigte neue Charta noch einen zusammengeführten Pull Request. Auch entscheiden sie nicht, ob Restmerkmale in dieser Gruppe bleiben, anderswo weitergeführt oder aufgegeben werden sollen.

Belegt ist etwas Engeres: Eine öffentliche Sicherheitsprüfung erkannte eine falsche funktionale Gleichsetzung. Ein Co-Chair stimmte zu. Eine Textkorrektur ist offen. Die verbleibende Governance-Aufgabe ist eine lesbare Disposition für die Eigenschaften, die der Patch nicht übernimmt.

Quellen

  1. W3C Strategy — WebRTC-Neuchartierung, Issue 563
  2. W3C — Entwurf der WebRTC-Working-Group-Charta 2026
  3. W3C charter-drafts — Pull Request 869
  4. W3C charter-drafts — vorgeschlagener Korrektur-Commit
  5. W3C — geltende WebRTC-Charta
  6. W3C — WebRTC Identity Candidate Recommendation
  7. RFC 9605 — Sicherheitsbetrachtungen zu SFrame
  8. W3C Process — Aufgabe unvollendeter Arbeit
  9. W3C Patent Policy
  10. Heng Lu — Minimum Initial Specification, Localized Future Decision und Voluntary Adoption