Zusammenfassung

  • W3C-Strategy-Issue 560 ist offen, bezeichnet WebMCP als wesentliche Chartaänderung und nennt keinen erwarteten Abschluss der Überarbeitung.
  • Pull Request 829 fügt native Agentenintegration, imperative JavaScript-Werkzeuge und deklarative HTML-Formularannotationen hinzu; WebMCP wäre ein vorläufiges Arbeitsergebnis.
  • Der Patch ändert die namentliche Koordinationsliste nicht, obwohl das Strategy-Issue Prüfungen durch HTML, ARIA, TAG, SING und Privacy verlangt.
  • WebKit hält eine ablehnende Position, Mozilla bleibt neutral, APA unterstützt den heutigen Bericht nicht und die Bedrohungsmodellierung läuft. Keiner dieser Einträge ist eine W3C-Entscheidung.
  • Vor dem Advisory Committee Review sollte eine Matrix Umfang und Verantwortliche verbinden, dabei Eigentum, Abhängigkeit, Beratung und Querschnittsprüfung trennen und kein automatisches Vetorecht schaffen.

Vorgeschlagen ist ein neuer Auftrag, nicht nur ein neues Wort

Der Dokumentstatus setzt die Grenze der Aussage. Issue 560 wurde am 9. Juni 2026 eröffnet, ist weiterhin offen und führt das erwartete Ende der Überarbeitung als unbekannt. Pull Request 829 ist ebenfalls offen und ungemergt; sein Head besteht aus einem einzigen Commit vom selben Tag. Belegt ist somit ein vorgeschlagener Umfang. Nicht belegt sind eine genehmigte Charta, die Annahme von WebMCP oder ein bereits laufender Browserstandard.

Inhaltlich ist der Schritt dennoch groß. Die geltende Charta konzentriert sich auf maschinelles Lernen und Inferenz: die niedrig angesetzte WebNN-API, den Zugriff auf Plattformbeschleuniger und möglicherweise das Laden von Modellen. Der Patch macht aus einer Web API mehrere und ergänzt die „native Integration von KI-Agenten im Browser“.

Der imperative Zweig ließe Webanwendungen JavaScript-Funktionen als strukturierte Werkzeuge registrieren, aktualisieren und entfernen, einschließlich Beschreibungen und schematischer Eingaben. Der deklarative Zweig würde Standard-HTML-Elemente, vor allem Formulare, so annotieren, dass ein Agent Aktionen maschinenlesbar entdeckt. Hinzu kommen Browser-Vermittlung, Same-Origin-Grenzen, Nutzerautorisierung und die unmittelbare Auslösung von Seitenfunktionen.

Damit berührt die Charta Browserausführung, HTML-Autorenmodell, Barrierefreiheit und Sicherheitsgrenzen von Agenten. Der Status „tentative“ erhält spätere Hürden: Fortschritt in der Inkubation, Interesse mehrerer Implementierer und Konsens in der Working Group. Er macht aus einer Verschiebung des Mandats jedoch keine redaktionelle Kleinigkeit.

Die Koordinationsliste folgt der neuen Reichweite nicht

Der Änderungsvorschlag bearbeitet Umfang und vorläufige Deliverables, nicht aber den Abschnitt über zusätzliche technische Koordination. Der öffentliche Entwurf nennt weiterhin die Web Machine Learning Community Group, die GPU for the Web Working Group, die WebAssembly Community Group, die WebRTC Working Group und die Technical Architecture Group. Außerhalb des W3C steht ECMA TC39.

Daneben verpflichtet ein allgemeiner Absatz zu Querschnittsprüfungen in Barrierefreiheit, Internationalisierung, Datenschutz, Sicherheit und Architektur. Dieser Satz ist wichtig; die Charta behauptet keineswegs, ohne Prüfung vorgehen zu können. Doch eine allgemeine Prüfpflicht und eine namentliche Abhängigkeit lösen unterschiedliche Probleme.

Eine Querschnittsprüfung misst den Text an übergreifenden Anforderungen. Ein Abhängigkeitseintrag bezeichnet die fremde Schicht, das betroffene Ergebnis und den Kommunikationsmechanismus. Spezifikationseigentümer, Mitverantwortliche, beratene Gruppe und Reviewer besitzen nicht dieselbe Autorität. Wenn ein Entwurf unmittelbar HTML-Formulare auf Agentenaktionen abbildet und Fragen zu ARIA oder Accessibility Tree erzeugt, müssen diese Rollen auseinandergehalten werden.

Das Strategy-Issue kennt die beteiligten Akteure bereits. Es fordert Beiträge von HTML, ARIA, TAG, Security Interest Group und Privacy. Öffentliche Kommentare zeigen ebenfalls reale Koordination. Die Lücke liegt zwischen dieser Tätigkeit und der formalen Charta: Das beantragte Mandat enthält noch keine namentliche Karte von Verantwortungen und Kommunikationswegen.

Vier Prüfakten haben vier verschiedene Bedeutungen

WebKit verzeichnet eine ablehnende Position. Die Begründung warnt vor einer parallelen Oberfläche für Agenten, ordnet einige offene Semantikfragen HTML und Barrierefreiheit zu und bezweifelt, dass Machine Learning der richtige Ort für die Weiterentwicklung dieser Schichten ist. Ein Apple-Vertreter schrieb später im Charta-PR, Apple werde bei einem Merge voraussichtlich eine formale Einwendung erheben, sei aber für einen anderen W3C-Ort offen. Das ist ein erheblicher Einwand, jedoch weder Veto noch abschließende Disposition.

Mozilla führt WebMCP als neutral. Die Stellungnahme sieht möglichen Nutzen und zugleich ungelöste Risiken, Benennungsfragen, Grenzen des Ökosystems sowie Unklarheit zwischen imperativem und deklarativem Ansatz. Kommentare von Ende August setzen diese Diskussion fort. Neutralität ist keine Implementierungszusage, aber auch keine Ablehnung.

Der Kommentar der Accessible Platform Architectures Working Group vom 27. August ist enger gefasst. Die Beteiligten sehen experimentelles Potenzial, etwa für kognitive Barrierefreiheit, unterstützen den heutigen Community-Group-Bericht aber nicht. Sie fragen nach sichtbarer Entdeckung, Prüfung, Zustimmung, Abbruch und Rückgängigmachen von Agentenaktionen. WebMCP-Informationen sollen vom Accessibility Tree getrennt bleiben; eine Spaltung menschlicher und agentischer Fähigkeiten gilt als Risiko. Der deklarative Weg erscheint tragfähiger, bleibt jedoch experimentell.

Die Sicherheitsprüfung befindet sich wiederum in einer anderen Phase. Das Juli-Protokoll der Security Interest Group untersucht Vertrauensgrenzen zwischen Seite, Browser, Agent und Nutzer, außerdem Werkzeuginhalte, Cross-Origin-Fragen, Sichtbarkeit und Lebensdauer. Dokumentiert ist ein iteratives Bedrohungsmodell, kein Sicherheitsurteil.

Ablehnung, Neutralität, qualifizierte Nichtunterstützung und laufende Analyse sind keine Stimmen derselben Abstimmung. Ein vermeintliches Gesamturteil der „Community“ würde die Unterschiede auslöschen, die das Charta-Verfahren gerade verarbeiten soll.

Prozessregeln verlangen Abhängigkeiten und nachvollziehbare Antworten

Nach dem W3C Process muss eine Working-Group-Charta Umfang und Ergebnisse definieren sowie Abhängigkeiten von und zu anderen Gruppen identifizieren. Sind andere Gruppen von einem Ergebnis abhängig, sollen Kommunikationsmechanismen genannt werden. Vor dem Advisory Committee Review ist die breite Prüfung abzuschließen; Einwände gegen den Entwurf müssen förmlich behandelt, Lösungen in einer Disposition of Comments verfolgt und aufrechterhaltene Einwendungen hervorgehoben werden.

Daraus folgt weder Miteigentum jedes betroffenen Gremiums noch ein einseitiges Vetorecht jedes Reviewers. Die gesuchte Matrix darf kein verborgenes Vetoregister sein. Sie soll zeigen, wer eine Schicht verantwortet, wie eine Unvereinbarkeit weitergegeben wird und wer über die Disposition Rechenschaft ablegt.

Bei einer Umfangserweiterung gewinnt das an Bedeutung. Ein neues Recommendation-track-Ergebnis außerhalb des bisherigen Deliverable-Umfangs ist eine wesentliche Chartaänderung und bedarf AC Review. Bis dahin bleibt die aktuelle, bis 30. April 2027 laufende Charta das wirksame Mandat und weiterhin auf die bestehende Machine-Learning-Arbeit gerichtet.

Eine Verantwortungsmatrix ohne vorweggenommenes Venue-Urteil

Neben dem Diff könnte eine öffentliche, versionierte Matrix stehen. Jede Zeile enthielte Charta-Revision und unveränderlichen Commit, die vorgeschlagene normative Oberfläche, die betroffene Plattformschicht, die beantragte Autorität der Working Group und das namentliche abhängige, betreuende oder prüfende Gremium. Die Rolle wäre als Miteigentum, Abhängigkeit, Liaison, Beratung oder Querschnittsprüfung klassifiziert. Hinzu kämen öffentlicher Kanal, Prüfauftrag und Antwort, offener Einwand samt Begründung, Annahme- oder Übertragungsauslöser, Reife- und Patentstatus, nächster Verantwortlicher und Prüftermin.

Für deklarative Formulare könnte eine Zeile die HTML-Schicht und zuständige Spezifikationsakteure nennen, ohne alle zu WebMCP-Mitherausgebern zu erklären. Bei Barrierefreiheit ließen sich ARIA- oder Accessibility-Tree-Zuständigkeit und die horizontale APA-Rolle trennen. Sicherheit erhielte den Status „Bedrohungsmodell in Arbeit“ statt eines grünen Hakens. Browserpositionen blieben von Working-Group-Konsens und W3C-Genehmigung getrennt.

Die Matrix entscheidet nicht, ob WebMCP in Web Machine Learning, in eine neue Gruppe, in mehrere koordinierte Foren oder ausschließlich in die Community Group gehört. Sie verhindert, dass diese Entscheidung im unscharfen Wort „Koordination“ verschwindet.

Heng Lus Grundsatz einer minimalen Anfangsspezifikation begrenzt das gemeinsame Register: Es sollte nur die für Koordination nötigen Verbindungen festhalten und spätere Entscheidungen den Eigentümern der jeweiligen Schichten überlassen. Ziel ist keine Zentralisierung aller Agentenfragen, sondern der Schutz davor, dass eine Charta durch Schweigen benachbarte Autorität übernimmt.

Was die Akten nicht belegen

Eine fehlende Nennung beweist nicht, dass keine privaten Treffen oder informellen Gespräche stattfanden. Apples Ablehnung ist keine W3C-Ablehnung. Mozillas Neutralität begründet keinen Implementiererkonsens. APA verwirft nicht jede mögliche Agentenarchitektur, und das Sicherheitsprotokoll beweist keine Unsicherheit des Systems.

Auch Annahme, Interoperabilität und Einsatz sind nicht belegt. WebMCP bleibt ein Community Group Report, der Charta-Patch bleibt offen. Inkubation, vorläufiger Charta-Eintrag, formale Annahme als Working-Group-Arbeit, Working Draft und Recommendation sind getrennte Zustände.

Der belastbare Governance-Befund ist enger: Ein offener Patch würde einer Working Group normative Erkundung an HTML- und Browser-Agenten-Grenzen erlauben, während die namentliche Koordinationsliste dem alten Mandat folgt. Öffentliche Prüfung macht Akteure und Fragen sichtbar. Vor dem Übergang von Umfang zu Mandat müssen daraus Rollen, Kanäle und nachvollziehbare Dispositionen werden.

Quellen

  1. W3C Strategy — Issue 560 zur Web-Machine-Learning-Charta
  2. W3C charter-drafts — Pull Request 829
  3. W3C charter-drafts — Commit zum WebMCP-Umfang
  4. W3C — öffentlicher Entwurf der Web-Machine-Learning-Charta
  5. W3C Process — Inhalt einer Charta
  6. W3C — geltende Web-Machine-Learning-Charta
  7. WebKit — Standards Position zu WebMCP
  8. Mozilla — Standards Position zu WebMCP
  9. WebMCP Issue 65 — APA-Prüfung zur Barrierefreiheit
  10. W3C Security Interest Group — Protokoll zum WebMCP-Bedrohungsmodell
  11. Web Machine Learning Community Group — WebMCP-Bericht
  12. Heng Lu — Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption