Summary

  • W3C Strategy issue 560 remains open, calls WebMCP the substantive change to the Web Machine Learning charter and lists the expected end of refinement as unknown.
  • Open pull request 829 adds native agent integration, JavaScript tool registration and declarative HTML-form annotations to scope, with WebMCP identified as a tentative deliverable.
  • The patch does not change the charter’s named coordination list, although the Strategy issue itself calls for review by HTML, ARIA, TAG, SING and Privacy actors.
  • WebKit records opposition and a venue objection, Mozilla remains neutral, APA does not support the current Community Group report, and security threat modelling is still in progress. None of those records is a W3C decision.
  • Before Advisory Committee review, a scope-owner coordination matrix should connect each affected platform layer to a named role, communication path and disposition without turning review into an automatic veto.

The diff changes authority, not just vocabulary

The proposed Web Machine Learning charter is still a draft. Strategy issue 560 was opened on 9 June 2026, remains open, and describes its refinement end as unknown. Pull request 829 is also open and unmerged. Its one head commit dates from the same day. The evidence therefore supports “scope proposed,” not “scope approved,” “WebMCP adopted” or “browser standard underway.”

The proposed change is nevertheless substantial. The active Web Machine Learning charter is built around machine-learning inference: a low-level WebNN API, access to platform accelerators and possible model loading. The patch changes the singular “Web API” to plural and adds “native AI agent integration in the browser.” It then introduces a second family of capabilities.

One branch is imperative. Web applications could register, update and remove JavaScript functions as structured tools, with descriptions and schema-shaped inputs. The other is declarative. Standard HTML elements, especially forms, could be annotated so an agent discovers machine-readable actions. The patch also names browser mediation, same-origin boundaries, user authorization and direct actuation of page features.

That is not a cosmetic insertion into an existing machine-learning deliverable. It reaches browser interfaces, HTML authoring, user-agent policy, accessibility experience and security boundaries. Calling WebMCP “tentative” correctly preserves later adoption gates. It does not make the scope addition institutionally small.

The coordination table does not move with the scope

The patch modifies scope and tentative deliverables. It does not modify the additional technical coordination section. The public base draft continues to name the Web Machine Learning Community Group, GPU for the Web Working Group, WebAssembly Community Group, WebRTC Working Group and Technical Architecture Group. Its external list names ECMA TC39.

There is also a general paragraph requiring horizontal review for accessibility, internationalization, privacy, security and architecture. That paragraph is important. It shows that the charter does not pretend WebMCP can advance without review. But a general review duty and a named dependency record do different jobs.

A horizontal reviewer tests a draft against cross-cutting requirements. A dependency entry can identify which other body owns a layer, which deliverable is affected and how changes are communicated. A co-owner, liaison, consulted group and reviewer do not carry the same authority. When a proposal maps directly to HTML forms and raises questions about ARIA and the accessibility tree, the difference should be explicit.

Strategy issue 560 already knows the missing actors. It says outreach is needed from HTML, ARIA, TAG, the Security Interest Group and Privacy participants. That makes the gap unusually visible: the issue names the review network, while the charter diff that would grant scope does not yet turn that network into an owner-and-communication map.

The observation is not that coordination failed to happen. Public records prove the opposite. The observation is that coordination activity has not yet been translated into the proposed charter’s attributable structure.

Four review records are four different states

The implementer and reviewer records should not be blended into a synthetic “community view.” They do not say the same thing, and none decides the charter.

WebKit records an oppose position. Its detailed comment argues that the proposal creates a parallel agent-facing surface, that some gaps belong in shared HTML and accessibility semantics, and that the Machine Learning venue is wrong for deciding how those layers evolve. Apple’s representative later wrote on the charter pull request that Apple would expect to file a formal objection if the patch merged and was open to a different W3C venue. That is a serious objection. It is not a veto, a disposition or proof that every WebMCP use case is unsound.

Mozilla’s recorded position is neutral. Its review sees a potentially valuable abstraction and also unresolved risks, naming questions and ecosystem limits. Late-August comments show continuing discussion over imperative and declarative designs. Neutrality is not implementer support, but it is also not opposition. The state is “questions remain while design discussion continues.”

The Accessible Platform Architectures Working Group’s 27 August comment is more specific. APA participants see promise for experimental assistive technologies, particularly for cognitive accessibility, but say they do not support the current Community Group report. They distinguish WebMCP information from the accessibility tree, warn that human-facing and agent-facing capabilities could diverge, and ask where users discover, review, approve, cancel and undo agent actions. Their comment finds the declarative direction a stronger starting point while keeping it experimental.

Security review is at another stage. The July Security Interest Group minutes frame trust boundaries among sites, browsers, agents and users; they discuss tool content, cross-origin exposure, user visibility and tool lifetime. The minutes describe an iterative threat model, not a completed security endorsement or rejection.

A good charter record preserves those four states separately: opposition with a venue rationale, neutral implementer review, qualified accessibility non-support and continuing security analysis. Counting them as one consensus signal would erase the very evidence that refinement is supposed to process.

W3C Process asks for dependencies and dispositions

The W3C Process gives the proposed repair a formal basis. A Working Group charter must define scope and deliverables. It must identify dependencies on and by other groups. Where other groups depend on its deliverables, the charter must identify communication mechanisms. Before Advisory Committee review, wide review must be completed and issues against the charter draft must be formally addressed, with resolutions tracked in a disposition of comments and sustained objections highlighted.

The Process does not say that every affected group becomes a joint owner or can block the charter. Nor should a coordination table become a disguised veto register. It requires enough structure to see who depends on whom, how information crosses the boundary and the disposition of a filed issue.

This matters more when scope expands. A new Recommendation-track deliverable outside an existing deliverable’s scope is a major change, not an editorial adjustment. WebMCP’s proposed path therefore deserves the same precision as the API itself: the authority to work, the layers affected, the groups responsible for those layers and the decision that resolves overlap.

The active charter remains relevant during refinement. It runs through 30 April 2027 and continues to authorize the existing machine-learning work. An open patch does not erase that mandate or create a second one. The proposed owner map would make the eventual handoff legible without pretending that the new authority already exists.

A scope-owner matrix, not a venue verdict

A compact public matrix could sit beside the charter diff. Each row would identify:

  • the charter revision and immutable patch being reviewed;
  • the proposed normative surface, such as imperative tool registration or declarative form annotations;
  • the affected platform layer, including browser execution, HTML, accessibility semantics or agent security;
  • the authority proposed for the Web Machine Learning Working Group;
  • the named dependent, steward, liaison or horizontal-review body;
  • that body’s role: co-owner, dependency, consulted group or reviewer;
  • the public communication channel and review request;
  • the response, unresolved objection and stated rationale;
  • the adoption, transfer or rescoping trigger;
  • the patent-policy and document-maturity state; and
  • the next accountable actor and verification date.

For declarative HTML forms, the row might identify the HTML layer and the bodies whose specifications or review mandates are affected, without assuming that all of them co-edit WebMCP. For accessibility, it could separate ARIA or accessibility-tree ownership from APA’s horizontal-review role. For security, it could show an in-progress threat model rather than a green check. For browser implementation, it could keep vendor positions separate from Working Group consensus and W3C approval.

This does not decide whether WebMCP belongs in Web Machine Learning, a new group, WHATWG, multiple coordinated groups or no standards track at all. It prevents that decision from being hidden inside a generic word such as “coordination.”

Heng Lu’s minimum-specification discipline supplies the constitutional limit. The common record should be no thicker than coordination requires, and later technical choices should remain with the actors that own them. Applied here, the matrix would not centralize every agentic-Web question in one W3C group. It would identify the minimum joins needed to keep one charter from silently inheriting authority over adjacent layers.

What the record does not prove

The public coordination list does not prove that no private, informal or meeting-based coordination occurred. Apple’s opposition does not establish a W3C rejection. Mozilla’s neutrality does not establish implementer consensus. APA’s comment does not reject every possible agentic-Web design, and the security minutes do not establish that WebMCP is unsafe.

The current record also does not prove adoption, interoperability or deployment. The WebMCP document is a Community Group report. The charter patch is open. Tentative status still requires incubation progress, interest from multiple implementers and Working Group consensus before adoption as Recommendation-track work. Advisory Committee review and a W3C charter decision remain separate later states.

The verified governance fact is narrower. An open patch would give one Working Group authority to explore normative surfaces that name HTML and browser agents. The same patch leaves its named coordination table on the older machine-learning lineage. Public review has now made the affected actors and unresolved questions visible. The next documentary step is to connect those actors to roles and dispositions before scope becomes mandate.

Sources

  1. W3C Strategy — Web Machine Learning charter issue 560
  2. W3C charter-drafts — pull request 829
  3. W3C charter-drafts — WebMCP scope commit
  4. W3C — public draft Web Machine Learning charter
  5. W3C Process — content of a charter
  6. W3C — active Web Machine Learning charter
  7. WebKit — WebMCP standards position
  8. Mozilla — WebMCP standards position
  9. WebMCP issue 65 — APA accessibility review
  10. W3C Security Interest Group — WebMCP threat-model minutes
  11. Web Machine Learning Community Group — WebMCP report
  12. Heng Lu — Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption