Meeting minutes
Anssi: as a reminder, we'll use IRC-based queue management in this meeting:
https://
Anssi: to suggest agenda topics, use Agenda+ label, e.g.:
Anssi: please welcome our latest new participants
… Severin Ferrand from Google
… Tyler Duprey, Neelakandan NC and Sam Bhattacharyya joining as individual contributors
… welcome!
Announcements
TPAC 2026
Anssi: TPAC 2026 is in Dublin, Ireland on 26-30 October 2026
… during that week, the W3C groups gather to resolve challenging issues and discuss future directions for the web platform
… TPAC group meetings take place Mon, Tue, Thu and Fri
… Wed is for breakout sessions and social events
… I believe this Community Group wants to meet during the TPAC week
… in the past we have met on Tuesday
… assuming also other groups stick with their earlier schedules, that is my default preference to avoid conflicts
… but I'm open to other suggestions
… some of the groups have shared their schedule preferences already:
https://
Anssi: TPAC 2026 website is not yet live, I'll share more information when it becomes available
Anssi: questions, comments?
Dominic: I don't have a TPAC plan yet, Tuesday sounds good
Prompt API
Repository: webmachinelearning/prompt-api
Model neutrality
Anssi: issue #169
<gb> Issue 169 [Tag Review] - Model selection and availability (by etiennenoel) [Agenda+] [tag-tracker]
Anssi: we will review and discuss the proposed solution to the model neutrality issue
… this was one of the two issues Mozilla brought to the group's attention
… Reilly proposed a solution to address the model neutrality issue by requiring implementations to use either a model with a permissive license or a model provided by the underlying platform
Reilly: high-level point, when an API requires a model, implementations that don't have their own they should be able to use the platform provided model
… when there's an open source model implementation can use that
Benjamin: Jake raised a point that models often come with T&Cs
… having T&Cs tied to the Web API was one of the Mozilla's standards position concerns
Reilly: IANAL, but I think the goal of using open-source models is to help with T&Cs
Tom: should we mention open-weights explicitly?
RESOLUTION: Prompt API specification to require conformant implementations to use a permissively licensed model provided either by the implementation or the underlying platform. As further work, determine what criteria makes sense exactly for such models. (issue #169)
WebMCP
Repository: webmachinelearning/webmcp
<gb> Issue 169 [Tag Review] - Model selection and availability (by etiennenoel) [Agenda+] [tag-tracker]
WebMCP wide review
Anssi: I've kept the horizontal group chairs up to date with our progress
… for privacy review specifically there was a suggestion for this group to highlight to the reviewers specific questions or technical issues
… for example: "what does Privacy WG think about X approach to Y"
… "does anyone in Privacy WG have experience or suggestions for how we could achieve X in a privacy-preserving manner”
… this helps focus reviewers' attention to the most important issues, and also helps to get more specific feedback from the reviewers
Anssi: I called for a final review of the updated materials before we submit for the wide review, to ensure we have consensus on the content of the submission
<gb> Pull Request 195 Add security and privacy questionnaire (by victorhuangwq) [Agenda+]
Anssi: I believe the updated explainer is in a good shape
… similarly, S&P considerations section is in a good shape
… S&P Questionnaire seems to be soon ready to be merged as well
Anssi: for the S&P Questionnaire PR, I'd like to check the few open discussions there:
Anssi: Johann, Benjamin?
Johann: I don't think I have a strong position on this, it is channel similarly to other APIs, would be appropriate to call the API out
Benjamin: agree with Dominic's point
… this is just part of browsing with this type of user agent, does not change the threat is a potential approach
Johann: theoretically could create a deterministic script that uses WebMCP to input to the tool, don't think this should block
Benjamin: agree this should not block the PR
Johann: also want to avoid make this look like this would be a novel concern with the API
09. Do features in this specification enable access to device sensors?
Victor: both 07 and 09 questions are pretty similar
… my thought on this is that, I'd try to answer the questions in a way they are intended to be answered to
Johann: happy to resolve as "no" and say user agents can already expose such information to websites
Anssi: with those two discussions settled, we can merge #195
<gb> Pull Request 195 Add security and privacy questionnaire (by victorhuangwq) [Agenda+]
Anssi: and execute the resolution from our last meeting to stage the review requests for final look before submission
… the spec editors are free to stage those review requests at their discretion, but I propose we do it in a timely manner to not delay the start of the review process
… the editors can grab the markdown templates from:
TAG review request ("Early design/incubation review")
Privacy review request template ("Request review for another type of spec")
Security review request template ("Request review for another type of spec")
Anssi: specifically in the TAG's "You should also know that..." and Privacy and Security WG's "Other comments" sections we are expected to highlight to the reviewers specific questions or technical issues we want feedback on, as I mentioned earlier
… any questions?
Brandon: the ask is to stage the templates in our WebMCP repo and when group has consensus submit to TAG, Security and Privacy WGs
RESOLUTION: The group approves the updated review materials (explainer, S&P considerations, S&P questionnaire). The spec editors will stage the review requests in WebMCP repo for the TAG, Privacy WG and Security WG, ensuring that specific questions or technical issues are highlighted to the reviewers in the appropriate sections of the review requests. (issue #195)
Human in the Loop support for non-browser clients
<gb> Pull Request 204 Replace requestUserInteraction with requestUserInput (by bwalderman)
<gb> Issue 165 Human in the Loop support for non-browser clients (by MiguelsPizza) [Agenda+]
Anssi: earlier we resolved to form a concrete design for user interaction to satisfy non-browser client Human-in-the-Loop use cases
… Brandon contributed a proposal for requestUserInput() "interactive", "form" and "url" modes inspired by the MCP Elicitation spec
… this replaces the current requestUserInteraction()
… these three modes are designed to cover a range of Human-in-the-Loop use cases for non-browser clients
… Alex seems to be in support of the three modes
… Dominic suggests in PR #204 that Chrome is interested in supporting the "interactive" mode initially
Brandon: interactive mode is still for browser client even if this was filed for non-browser clients
… consensus to focus on these three modes in some order, and "interactive" seems to be the first priority
… questions what happens for in-page agents
… when user input is called, what's not clear is how an in-page agent gets a notification when UA is called
… those are the simplest, page registering the tool takes input and fullfills the request
… "form" and "url" are more complicated, the agent is responsible for rendering the response and pipe it back to the tool
… in my latest comment I posted a few mechanisms asking for feedback from group
Dominic: I was originally more into "form" mode that keeps the user interaction in UA
… I think I've become more sceptical of this one, in fully remote flows, browsing happening in the server, agent UI connected to e.g. Codex
… most of the tools are equipped for local or remote, and making websites aware of this complicates this somewhat
… driving things via VM somewhere, requires input from the user
… need to expose this via an agent harness
Dominic: trying to keep the browsing use case in mind, while not stifling the remote use cases
… critique with "form" and "url" modes is the tool can already choose to navigate to drive interaction on a different site
Brandon: I do see the critique of the "form" mode, I have received similar feedback from others, agents optimized for browsing the web, they need to know how to solicit information from the user
… agents have their own way to get this information
… the "url" mode, however, in local browsing scenario the web page can open a new tab or a new window, but "url" mode helps when running on a server, user interacting indirectly via a mobile chat app, for example
… "interactive" mode first priority, "url" mode second
Alex: would be helpful to talk why elicitation is in MCP spec, the reason is security, secure credentials you put in the agent
… in elicitation, you input credentials in a form, not into the agent's context
… "url" solicitation makes sense
Brandon: about security, in MCP security, "url" is for sensitive flows as Alex explained, flows that do not go via agent
… for "form" elicitation, however, the frontend agent renders HTML and the form collects information and passes that back to the tool, never go via the LLM's context
… the tool listening for information, the agent can see this information even if the LLM does not
… from tool server's point of view the "form" does not resolve all security issues, however, "url" solves the sensitive information issue
Dominic: "form" makes sense for MCP tools because they don't have forms similarly to HTML
… our version of "interactive" makes sense as an analog to MCP's "form" mode
… I see value in giving "url" back to the user
… in the remote case, if the tool says I need to type in information into the form, I trust the agent's UI
… we don't need to give URL back to the user, but navigate to a different tab
Dominic: I see value in having the user visit something outside of the space where agent is operating
Alex: good point, originally I thought about Cloudflare's implementation
… guidance how to achieve how they are approaching the issue would be helpful
Alex: if there was URL once visited to load credentials, surfaced as a regular solicitation, maybe we don't need a separate channel to send the URL through
Brandon: one possibility to add, say we add "url" mode, when the tool requests, this is a suggestion to the browser that can decide based on context whether to open the URL if it knows the user has in-browser agent open
… if this is remote agent, then forward the request to the remote client to open the URL
Dominic: the browser does not always know an agent is driving the experience to be able to pass back
<AlexN> +1
<brwalder> +1
<AlexN> +1
RESOLUTION: The group agreed to initially specify the "interactive" mode in PR #204 and will continue discussion on "form" and "url" modes. (issue #165, PR #204)
Register agent skills
Anssi: issue #161
<gb> Issue 161 Proposal: Skills — workflow-level context for tool composition (by Idan-Levin) [Agenda+] [backlog]
Anssi: this is a proposal to let pages register skills
… "tools can tell agents what a site can do, but skills tell agents how to do it well."
… strawman proposal navigator.modelContext.registerSkill()
… independent of registerTool()
… registerSkill() takes as input a dictionary with name, description, instructions, tools, context, annotations
… an experiment by Andre demonstrated you can also create the skills-as-tools by registering each skill as a zero-argument tool
Anssi: Andre suggests there's value on helping agents to differentiate skills from tools
… David points out a tool with readOnlyHint could do the same
… how does the group prefer to proceed with this, any comments?
Dominic: Chrome thinks tools could allow orhestration, we don't know how granular tools will be written, or whether we need this orchestration layer
… would like to get feedback from OT on this
… potentially a lot of value in such an explicit skill registration mechanism
Manage agent memory
Anssi: issue #29
<gb> Issue 29 Allow developers to manage Agent's memory (by khushalsagar) [Agenda+]
Anssi: an issue opened a while ago by Khushal based on Nitin's idea
… MCP resources can provide contextual information to agents beyond current DOM data
… this enables access to implicit application memory such as shopping cart items or other user-relevant context
… the first question to the group is should WebMCP allow developers to manage agent's memory?
… if there's interest, I'd welcome contributions to the issue on specific use cases and design proposals for how this memory management could work in practice
Khushal: this was filed early on, not actively working on this right now
… a lot of this can be represented by tools
… tools such as "get cart items"
… prefer to look how developers would use this, learn via OT feedback, and if developers indicate interest we can look at a proper abstraction for this feature