Christian: Saw discussion from yesterday.

Marcos: Next step of the discussion is gathering the independent thoughts. Discussions around moving this to a WG. Independent from the WebKit position, I documented the concerns in the Slack. I am very concerned and ask the rest of the TAG to have a look. Might have the most significant impact on web architecture I’ve seen, and quite naively so. Needs a larger TAG reviewership because of the API shape and impact.

Slack: https://w3ctag.slack.com/archives/C03RSJGSCJD/p1779960423515319

Matthew: I'm pretty concerned about this for a number of reasons, privacy concerns, whole sort of meta concern about this is very new. We don’t know where it’s gonna go. But: People want to do stuff like this. So if we’re going to say no, can we offer a subset or a minimal part of it that can be used by people to experiment (the web builds itself; people are going to want to do this, so if we can give them a safe way to experiment that won't impact the rest of the platform until it's mature, and we're really sure it's OK to add any part of it)? The Group is aware of the S&P concerns, but the work carries on. From a11y perspective, there’s a lot of potential. Discovering help for very prevalent minor-to-moderate impairments is very difficult in traditional interfaces (people don't identify the barriers they face as ones that could be fixed; they don't discover helpful features that are present). One position wrt WebMCP is that the semantics added here could be added through the a11y tree. Really interesting question, can see both sides of the arguments. Some of the consequences have already come up, where people are stuffing stuff into ARIA attributes that are for agents, not for people. … AT is for people … We really need to think about the consequences.

Matthew: Here's one of the issues I mentioned re accTree: https://github.com/webmachinelearning/webmcp/issues/91

Christian: Remain positive, but let’s collect all of the valid feedback and put it into a draft comment, that is true.

Ehsan: Worried about privacy, group knows about it, and my gut feeling is: This will be exploited. We need to be careful. How can we direct it in the right way without blocking it? Even if the privacy concerns are serious, I think this is going to happen, so we should steer it.

Marcos: Believe this is very bad. webkit is very against this. we've encouraged them to stop that work and make a new forum.

what I realy like is that this really touches now on the semantic web stuff. we now come full circle on every aspect of what hte TAG has done for the past 20 years or whatever. it's so important for accessibility, privacy, not replicating what the web already does so beautifly, so important not to hand the web over to machines in such a naive way. there are use agents that I already know doing simiar stuff without dumping this problem on developers and keeping it in a privacy-insecure way.

Christian: we need a bigger discussion on this. Let's pick it up in next week's plenary.

Marcos: Intro to it... We have AI agents. They are being integrated into all sorts of software, including UAs. The agents can look into a page, figure out what the user is doing here and how can they help (give a summary of the page, or fill in forms, tools/tasks users might need help with). An example might be booking flights for the user (can help people for whom calendars present usability or accessibility barriers).

Idea of WebMCP: web pages are hard for AIs to figure out. We may need to do visual analysis. WebMCP gives agents data structures that, for example, describe a search form to the agent, which is more digestible. It will descirbe the inputs and outputs. We are defining tools (the web apps) that the agents can use to do tasks for the user.

Heather: what fundaementally makes WebMCP different from MCP?

Marcos: The explainer acknowledges this is a misnomer. MCP is a protocol layer Anthropic came up with. This uses concepts from MCP but isn't that. So it mirrors what MCP is but it isn't MCP.

Matthew: This is describing tools - the web apps - that have capabiltiies that your agent in the UA can then use.

Marcos: There are two parts to this - e.g. you could ask the agent to write you an email. Right now, the whole thing (including the subject) will just end up in the 'body' field becuase it doesn't understand the structure. WebMCP allows you to specify where is the subject, the body, etc.

... This is about in-page tooling (not things like (native) apps that the agent could open to do a task).

... I've tried to describe it factually. WebKit found some problems with it, which I will go into...

... It gets interesting when we consider the tooling and agents behaving as assistive technology.

Heather: Checking standards positions. Mozilla thinks it's interesting; monitoring what happens. WebKit is negative. Does Chrome have a position?

Marcos: They're the proponents. (I opened the TAG design-reviews issue.)

Heather: I feel like we need time to read this through in order to have a sensible conversation about it.

Marcos: One of the considerations architecturally is what primitives is this seeking to add to the platform.

Matthew: I haven't read the WebKit position, yet. I have some concerns, but I'll save them until tomorrow

Heather: any opinion?

Christian: q is how to tackle this. last time we worked on a google doc for prompt api. should we do the same for this?

Matthew: that is a good question. I am happy to contribute to those.

Marcos: I think we should do it differently than prompt one cause I wrote few version of the review and it got messy and we did not have concensus on the core ideas. I think we first need to gather all the positions in the google doc (I did that on slack briefly) and make sure if we cover all the ideas. I want to make sure if folks in data space has a chance especially Sarven and Hadley has more opportunitites to express ideas. I think if we don't get ahead of it, it is going to be a good response. Once the ideas colelcted, we can start generating a coherent opinion on this. Someone would need to lead on putting the ideas together.

Heather: why this is different than private gh?

Marcos: it is also fine in gh. Google doc can be more collaborative, I think it makes collaboration better.

Christian: can you send the slack message Marcos?

Matthew: on the procedure, is it correct that we have pieces collected and then [[??]]

Marcos: we can get our personal positions on gh or google doc, both would work but it is the process I suggest.

Matthew: I think I like the idea of google doc, as Marcos pointed it can get messy. If we want to collect them separately, we can put together a single response in gh private for the record.

Christian: the converstaion can be more efficient in google doc as it can make the conversations better too.

Heather: I like the idea of spanchatting to the private gh. I am happy to start the doc and will send it to the all.

Christian: great, any deadlines?

Heather: I think a week from today sound fair and we can discuss our position by next planery.

Marcos: it is doable. I finished it in an hour and it is not a big proposal.

Matthew: just a thought about deadlines, TAG has been asked to go to the charter of web ML WG. we wanat to make sure if this is based on the timeline they propose.

Ehsan: I think it has been discussed last Thursday.

Marcos: I don't think Apple will oppose to the idea so I don't think it is a blocker.

Heather: shall we take that as action item and move on?

Matthew: yes

Christian: We are collecting feedback on the GitHub thread before the plenary.

Christian: At WeAreDevelopers... received the same feedback that Marcos already shared; would WebMCP be necessary if people built their websites in a nice way, does it duplicate semantic web?

Marcos: What is your understanding of how WebMCP relates to the rest of our thinking about web architecture.

Brian: Matthew pointed out this morning that this would open a whole new set of privacy and security holes for which there are no known solutions. This is a lot more like web services; it is not MCP. If you want to find a way to advertise your webservices, fine. There are many semantic things already existing for that. There is a lot of complexity and risk for something that is upside-down in terms of architecture.

Marcos: Can you say more about the web services bit?

Brian: From the presentations I've seen, the rationale for why WebMCP is necessary is that it's very complicated to operate a site. You need to emulate the whole browser and understand CSS layout and window aspects and how to understand labels and so on... But the actual operations are hidden in the code today.

Marcos: Brian has hit on an important point. If you go to a website and it links to it's definition of where MCP is, it could in theory allow the agent to see there is a RESTful definition and I can operate the site independently of the UI, without muddying the whole thing by driving the site through WebMCP. There is a distinction between the agentic web (all RESTful, no HTML, etc) and the human web. And then there's the app side of things, and the app may advertise their own capabilities. Not necessarily to agents, but agents may leverage those capabilities.

Heather: When I went through this I focused on what I know most about - and the amount of tricky scenarios that they just glossed over with regard to authorization - they talk about fully autonomous agents, but... it can even be an interesting continiuum along the way. They talk about falling back, but how are they going to know - that all seemed unspecified as far as I could tell. They reached out of the web a bit - so it's like "here's all of the things that you could do on my site" but then there is also "check my email" which is a whole different thing.

Dan: I'm not directly involved in this, some of it is underspecified on purpose in order to allow for different interaction models. So I think the idea is "how do we bolt something into the platform that allows different AI models to interact with the web" - it is definitely interesting the different authorizations that Heather was talking about. I definitely think they could go into more details on those things. I like some of the things Marcos was saying about these sort of different levels. It might be good to invite them here to talk about it - it might be the most time effective way to do this.

Marcos: I absolutely agree we can have them in a call - but I think the motications are clear and the intents are good, but the approach really needs to be iterated on more.

Brian: Would you propose we offer feedback then invite them, or invite them first?

Marcos: It depends on whether if others understand what they're proposing. We could send what we have then have them come chat. I don't feel strongly about it.

Brian: We could say something like "We know people are interested in this problem; it is valid. But we don't think this is the way to go about it. Here are some questions we have."

Marcos: I want us to have a productive architectural discussion. I'm worried people are entrenched in their solution because they were so excited to put it together. But there does seem to be other ways to solve these problems. The TAG should suggest they take a step back architecturally because it touches so many things. We don't want to segment the web into multiple parts like this.

Dan: A lot of the security concerns raised on the thread reasonate with me. It would be interesting to hear how browsers are already managing this risk.

Marcos: The way Safari interacts through Siri is different than how people do. Things are sandboxed in different ways, and that's still different from how other browsers do it.

Brian: It's not just about interrogating the page. To query about how to do something, you need to know about the query API; you take actions and hit URLs to get enough information to have the page in context for the AI. If it was just asking questions about the text, we wouldn't be having this conversation.

Marcos: And that comes back to Heather's question about authorization. What happens if it hits an authentication prompt?

Brian: Their use cases focus a lot on purchasing online, so those are relevant questions. There is a workshop coming up on this. https://www.w3.org/2026/ecommerce-agents/cfp.html Sept 8-9.

Hadley: From the looks of it, we may be taking a strong stance on this. But instead of "we are against this" we use more like "we have serious concerns about this approach."

The other thing is since we rarely come out this strongly, we should reach out to proponents, the CG chairs, and have a conversation with them before sharing our review so they are less surprised and understand where we are coming from.

Luke: Agree with Hadley's point on the wording. Or some iteration.

Sarven: the type of solution they are offering, signalling at the weaknesses of how the web is working, how pages are published, how authors are making their documents available. So you've highlighted a problem, and maybe the solution is more towards fixing or improving those, as opposed to adding another technology. Accessibility of the potential actions is hard for random scripts to navigate around... why is that? We should look at improving that. "Great, you've pointed out something important. The solution to that might be different than you're proposing."

Heather: Agree with Hadley's approach, it doesn't shut the door re good / bad things. If this is going to be a TAG statement, we probably don't want to do that.

Lola: There is industry push for this and i think that complicates things a bit. Other tech proposed doesn't necessarily have that. That doesn't mean we need to agree to that but have to consider these things. And also think about the general direction of the web and how the web is moving. I haven't read the spec proposal yet, and if we are going ot be against it, and because of the context we are in, it'd be good to pull in the authors/chairs to discuss the issues and look into how to figure it out.

Matthew: Horizontal review groups have been asked "should this be part of the charter for the Web Machine Learning working group?" I agree that people want to do this, and I don't want to push them into doing it in less safe ways. At the same time, if we said we're ok with this, it would standardise a whole new set of security and privacy holes for which there is no known solution. So I agree with "let's work together, try and make it work."

Hadley: +1 to Lola.

Luke: In terms of positions, there is opposition from WebKit. I do agree with the perspective maybe wording it rather than saying this shouldn't be a thing, we could say, "here is a problem we see. There are holes in the security model here, and don't think it'll be solved appropriately."

Hadley: We had a number of situations in the past where we either published and watched the chaos, and that tends to lead to more opposition and blogposts, and our message, and then theirs, and it is not particularly collaborative. We have also talked with individuals as well, then they found that interesting/useful. So, just want to reiterate that we talk to them directly.

Marcos: Following on from our last discussion, the next step is to find time for them to come and join us in a conversation.

Lola: Privacy WG discussed WebMCP in their meeting last week. We didn't have time to complete the discussion there. Some strong opininons. They also wondered if we could have a Privacy WG, WebMCP, and TAG joint call. How does that sound?

Marcos: Sounds good but I think some key WebMCP contributors may be US West Coast.

Lola: Could just involve the people reviewing it.

Ehsan: I think that is a good idea; 1 hour wouldn't be long enough with lots of people; wouldn't lead to agreement.

Marcos: In the WebKit position I also said that we should have a workshop or simliar (multi-day) to figure out what is the agentic web, and positions, and do the standardisation properly. We need to solicit wider opinions. Good that we are getting some so far. As a community we need to create a new venue, have the discussion properly, and do the work in the traditional way that W3C starts work. Get people together, discuss the problem, propose a new CG or WG.

Lola: Two potential suggestions. First step: create a Slack channel and invite all the relevant people. At least have conversation going async there. In that channel you could schedule a series of meetings to discuss. Marcos, do you want to create it?

Marcos: Should do it on the W3C Slack. Will do.

Chair: Lola Odelola

Scribe: Dan Clark

Other Attendees: Andrew Nahas, Andrew Nolan, Julia Pagnucco, Brandon Walderman, Brian Kardell, Christian Liebel, Johann Hoffman, Liad Yosef, Luke Warlow, Matthew Atkinson, Mike Pennisi, Domenic Farolino, Philippe Le Hegaret, Sarah Drasner

Christian: When we screen proposals people who are interested assign themselves. For webcmp we are 4: marcos, ehsan, matthew, and me. Look at the proposal, explainer, early spec text, try to check them against design reviews and also the broader angle of 'is this a good fit for the web platform', does it make sense architecturally. Helpful to have various people on the review to get broad perspective. Regarding webmcp, also have the doc we shared with you. Can see the names of who wrote feedback text. I like the proposal. marcos and ehsan are critical. Points they raise are in that google doc. But they're not here, so hard for me to represent what they said but we'll try. How do we proceed? https://docs.google.com/document/d/1Ao32HZHk_VYzPRvUNLCKBNvpHk7naqqMqIpBc67fcsQ/edit?usp=sharing

Andrew Nolan: Should we still meet today?

Matthew: I can represent some of ehsan and my feedback.

Lola: Scheduling TAG is hard, let's keep going.

Domenic: We talked with Marcos a bit. I want to differentiate security concerns. When working with the W3C security interest group to come up with a thread model, I realized a lot of concerns were with general AI agents using the web. Agents can mix data, sloppy one can type SSN in pizza site...lots of ways to misrepresent and misuse the web. But we found it useful to raise that solving those problems probably needs to happen at a different layer from WebMCP. Agents are already using the web, representing the user, so tying the concerns to a specific proposal (WebMCP or separate declarative proposal) is the wrong layering. All the problems in that ecosystem happen without WebMCP too. If we tie it to WebMCP and that proposal dies, we still have all these problems. So WebMCP can layer on that security work. Security IG was sympathetic to that view. Even if agents using normal HTML form, they can mix data from origins, type in personal info inappropriately. We're working on mitigating that stuff but it's not specific to WebMCP.

Matthew: I take the point. Probably don't need to dig too deep into that on this call, but sounds reasonable. However, if we bake WebMCP into the platform, that's the introduction of agentic AI into the platform. Opens the door. You can use it now and it has those risks, but when you add to the platform we want to improve on the status quo. If sec/privacy issues are unresolved, we've made the situation worse. I think that's fundamental difference of perspective. Probably won't make progress on that issue but worthwhile to have it in the open.

Lola: +1 to matthew

Sarah: I agree with Matthew. Right now, agents scrape the DOM, which happens today. Further convo on that subject should look at what happens in practice. Saying don't do anything until it's resolved is infeasible, it;s already happening. Prompt injection already happening. WebMCP improves upon status quo. In convos around security, should focus on what happens if no WebMCP vs what happens with WebMCP. Concerned we're not representing authors and creators. Want them to have a voice vs this just happening to them.

Lola: Authors and creators of stories are not first in order of constituencies. User comes first. If benefits autjor but risks user security, have to take that seriously . Shouldn't standardize industry practice just because it exists. We have higher set of responsibilities. Should look at what's currently happening but shouldn't be main focus.

Domenic: It's more than differing perspective. Some of the solutions that are required to secure agents on the web are not solvable by a web API. No webidl to stop claude from reading my email and putting personal info in wrong website. Should build surface area to help agents not do that. We're working as API with the parts of systme that need to solve that. But solutions will not come from JS in renderer process in one frame. AI agents are much broader than that. Actual solution must come at different layer.

Christian: To Sarah -- I'm positive on this proposal, because if you do other AI stuff, the API feels just right. The way you'd write it on a different platform. Makes sense from developer POV. But does it have to be JSON schema, or can improve HTML, or form elements to make same thing happen? This is fair question. What are your thoughts?

Brian: We don't know what the future holds. Useful to have additional info like this in HTML even if not just for AI. Good for AI, for search...for potential extensions maybe. Better if we diversify the things we try. An efficient way for machines to talk to each other, they are talking each other like humans...shoulld explore more efficient things. I question if this is the thing. Don't have info to understand why other approaches were dropped as possibilities. Want to learn more. Why specifically this one. Doesn't seem like the most efficient way for machines to talk to each other.

Matthew: Will be comment from APA on a11y angle. Exciting things in here but also concerns. Will try to keep more general here. Norm is that when we add new features we try to add them in simple declarative way that solves most use cases. Tends to be more predictable, easier to make more private. Then if we find there are more complex use cases, followed by more complex imperative way. Here we're doing it the other way round. Curious about that. Key goal stated is allowing collab between agents and humans. A11y promise seems to come in there. But thing that's specced is API that agents can call that user can't see. And very general. Declarative thing is more pinned to tasks involving filling in forms, more bounded and safe. Why not experiment with declarative first?

Domenic: We're running Origin Trial experiment in Chrome now. A couple million declarative registreations, and [missed] other registrations. Declarative can't handle nested cases, streaming...some features we do declarative initially, but lots of important ones don't. Readable streams, important stuff in popover. Lots of important imperative APIs...service workers...this is fine, it makes web relevant. Limiting to declarative limits us being compatible with actual web ecosystem. How to keep in-page agents in scope without imperative API? Just scraping the DOM isn't enough. Other concerns like about running backgorund tools in service workeres. There's lots of use cases with native apps that use like Apple's native app intent framework. If we don't support those use cases in the web it risks being less relevant. Other parts of industry have converged around solutions that fit like this. We can do better job documenting that. But I really think if we want to upend industry state of the art, need strong evidence.

Sarah: Well said. Tied to point Lola made: user first is the goal. If site devs can't think through things that are user first, passing large token overhead can be less safe if no way to declare that content is read only. The more that site dev has agency over the experience, better for the user too. Standard HTML forms have problems representing real application workflows. See this in practice in existing apps. Declarative doesn't work well for how these sites manage state. We're getting feedback like this from sites like instacart.

Andrew Nolan: +1. When we talk to devs they never mention declarative, always imperative.

Brian: Because a lot of state lives only temporary in browser? Only way people can act on things is because happens to alraedy be loaded in browser. If so, we'd be best served by throwing multlple lines in the water, see which we can fish with. Still implies you have to load the page. Regular MCP is appealing because mostly declarative, can describe in one file. See that was given up on. But wonder if there are new ways to offer people to build apps that start by defining services, let you build UIs that integrate them in appealing ways.

Domenic: Reason people use imperative is because a lot of the tasks are not form-shaped. One example is filtering things on page, or adding overlay to picture editor. Forms default behavior is to just navigate. We find peopple want to hook into application code. Usually attach to submit event, if webmcp, do imperative work there. Is a weaker schema. Defining stronger schema end up looking like MCP.

Liad: Should separate core browsing that reiles on the existing architecture and state. If company wants to build accessibility for agents in other way, can do it without relying on web page. And generate UI for that. But it's different use case. Headless agents don't need to go through web.

Lola: Encourage proponents to think on user impact. Have heard lots of exisitng agents that do stuff on web. Want to understand need and desire for w3c in particular to stay relevant. Part of current climate is AI. User privacy, security, safety -- we've seen news about harm. While I understand need to not drop behind, hope folks are thinking not just how can we standardize, but how can we do better. Makes users AI interactions on the web better than what's commercially availabl.e

Domenic: Can you clarify? What is missing in the explainer we can clarify?

Lola: I'm just going by today's discussion. Lots on making sure we don't drop behind. For those who are working, I want them to hold users at forefront.

Domenic: WebMCP is the result of us trying to do that.

Sarah: Keeping users safe is my only interest here. WebMCP is a potential path to better user value and security. Framing might be off on security. Difference in stating there are technical limitations to what the web can do, the standard can do...if you are providing safeguard in mcp like read only hint, still relying on agent to do that appropriately. Maybe framing is off -- yes the whole motivation is keeping users safe. I think point Dom is making is it's impossible technically speaking to do it only in the web standard. Also looking into how else we can provide safety. Don't want it to be confused that we don't see that responsibility. we want to work with everbody here to make that as good as possible.

Matthew: I looked again at spec intro. Talks about agents and human collab. Appreciate what you said on the forms-only approach, this is much more general. But it says tools can be invoked by agents, browser agents, assistive tech...two distinct things mentioned: agents, which are general. That's different form agents that live in broser, or AT which is part of browser. Also mentioned headless scenario. No human driving it. Very different cases. Would it help to separate those out? Agents hosted in UA is separate from ones that aren't.

Andrew Nolan: When we originally wrote the proposal, one of the common questions was how this works. Could anything use it, does it have to be agent. Was helpful for people to understand that it doesn't. Agents are just the primary use case. If other tech wants to use these APIs, that's possible but not necessarily the focus.

Domenic: Not seeing why the distinction matters of in-browser or shipped separately. How the product chooses to expose tools, just like dev tools protocols...why does this have impact on webmcp spec?

Matthew: My assumption was that agent outside the browser would not have access to those internal browser mechanisms. So you answered it. I assumed we treated those differently, but if you say both have access to those APIs...if it's completely headless scenario, does it go to web page to get imperative endpoint, or do something completely separate? Other bucket is UA/AT provided agents, I want help doing something on it. If it would somehow have access to the APIs I agree it's not different.

Liad: This was my point from earlier. investigation into accessing contnt headlessly, that's different use case, doesn't have to go through browser. What we're talking about here is use case where we're interacting with website.

Domenic: Distinction is minimal from webmcp perspective. Devtools protocol could drive browser which then hits webmcp. Can't verify from API perspecitve whether human is driving. It's a product decision. So we're mostly treating them the same.

Lola: Aside from Ehsan and Marcos, I know Heather and Sarven also had feedback and questions. Reviewers here today, do you have enough for draft comment or need more discussion?

Matthew: Discussing in google doc, and found this very helpful. Might need another call.

Domenic: I'd love an investigation into why we think it's possible to close the agents using Web Gap just through markup, against the grain of what every AI company is doing. We can help document. But think it's incumbent on reviewers, if we're being pushed in a direction, to help supplement with evidence. Let's be honest about what other solution precludes, e.g. no headless usage from service worker...want to make sure we're weighing tradeoffs and deciding with evidence.

Lola: That's fair can you put that in the public issue or in google doc?

Domenic: I'll put it in TAG issue.

Brian: Why is there urgency?

Domenic: I don't think there is. We've gotten so much feedback, want to get wide horizontal review. Mostly that there's a lot of attention on it, want to get lots of eyes on it.

Lola: Maybe the urgency I was referring to is more bureaucratic. Do we need another call?

Christian: Reviewers will meet again. And look at google doc. And we'll see.

Lola: Pepople who weren't here might need to go to MCP folks rather than the other way round.