TPAC 2025 past calendar - Breakout Sessions

In the age of AI, can we devise AI agents to help to write and publish next generation standard specifications for the web?
In collaboration with AI KR CG. and in parallel with Community CG seeking to 'improve the process' This breakout session aims to a) review the standards drafting process as conducted by humans *experts, users, participants
b) collaborate to create tools to automate the standard drafting and publication process

In the age of AI, can we devise AI agents to help to write and publish next generation standard specifications for the web?

In collaboration with AI KR CG, Also meeting at W3C TPAC 2025 and in parallel with Community CG seeking to 'improve the process' This breakout session aims to

Summary review the standards drafting process as conducted by humans *experts, users, participants

b) collaborate to create tools to automate the standard drafting and publication process In principle system outline and DEMO on Colab

Two short drafts have been created for discussion on the AI KR CG WIKI and Github

Autofill is a key feature of the web that reduces friction for millions of users everyday. However, there are areas where Autofill as defined in HTML and as implemented in browsers fails to address website needs. One such area is in dealing with dynamically changing forms, especially address forms which are often dynamic - different geographies have different shapes and requirements for address input.

A proposal has been made to address (pun intended) this situation, but requires consideration and discussion as to whether it meets the needs and constraints of both browsers and websites (particularly e-commerce sites). See also issues https://github.com/WICG/address-autofill/issues/14 and https://github.com/WICG/address-autofill/issues/15 filed by Google Chrome.

The focus of this session will be on the above proposal, but we welcome all who are interested in how Autofill could be improved to make for a better experience for both users and websites!

An update on all the work that has been happening as part of Cookie standardization efforts, mostly under the Cookie Layering umbrella across different standards groups, notably:

• A new Cookie specification in IETF
• Updates to the HTML and Fetch specs
• Cookie Store in WHATWG

We'll also cover remaining work and discussion on what needs to happen next in Cookie land. Some topics:

• Dealing with diverged third-party cookie behaviors (see https://github.com/privacycg/proposals/issues/49)
• Aligning on a default behavior for cookie partitioning (also https://github.com/privacycg/proposals/issues/49)
• Dealing with SameSite inconsistencies and divergences across browsers
• Better WPTs for cookies
• ...?

Slack

The web is expanding constantly. Expansion of new technologies (AI, Digital Wallets) is happening faster than ever, shifting wildly society and the economy. W3C needs a consistent, strategic way to navigate those evolutions. The technology strategy initiative task force goal is to guidance to help W3C know when to address changes and innovation, when to ignore changes and innovation, and when there might be opportunity for W3C to instigate change.

W3C has been using minimally structured incubation pipeline that focuses on early exploration, open collaboration, and review over the years:

• Community Groups: WICG, Credentials, Machine Learning, …
• Workshops: Age-Based Restrictions on Content Access (2025, jointly with IAB), Smart Voice Agents (2026)
• Interest Groups: Media and Entertainment, Web Payment Security, Smart Cities, …
• W3C Team strategy pipeline: w3c/strategy issues

The Task Force would like input from the community. What new technology are we missing and, most importantly, why? How do we evaluate new technologies? What guiding principle are we missing? How do we prioritize?

I'd love to have a short conversation around PWA Widgets. PWA Widgets let developers provide configuration for dynamic OS-native widgets that can be made available for users, enhancing their experience with the PWA beyond the PWA's window. Think calendars, reading lists, and TODOs.

This session will cover the current state of different projects under the Web Monetization work, partnerships, and future direction.

With Web Monetization, we’re adding a new, seamless way for users to support the content they love — complementing existing models with real-time, streaming micropayments. The Web Monetization Extension makes it effortless for users to contribute on their terms, while giving content owners more opportunities to engage their audiences and diversify revenue streams.

We propose to structure the breakout around these main focus areas:

1. WM Extension – the browser extension implementation of the Web Monetization spec: status, adoption, compatibility, limitations.
2. WM Publisher Tools – the toolset for publishers/content owners (banner, link-tag, widget generator etc) to adopt Web Monetization.
3. WM Flows Spec – Walk through the flows as defined (e.g. how authorization happens, how the payment session is established, how streaming is maintained or rotated) and mention interactions between user agents, wallets, and publishers.
4. WM In-Browser Implementation / Prototype Demo – progress toward native or built-in browser support (vs only extension), including prototypes, engagements with browser vendors.
5. WM Standard / Spec Status – the specification itself: where it stands in the standards process, outstanding issues, interop, ecosystem feedback, next steps
6. All things feedback

Information about Chairs:

• Ioana Chiorean (ILF)
• Alex Lakatos (ILF)
• Alexander Surkov (Igalia)
• Sid Vishnoi (ILF, remote)

Ask anyone for the use cases for Decentralized Identifiers and Verifiable Credentials and you'll be told about driving licences, university degrees and digital identities, all of which are variations on a theme of an authority issuing a credential to an individual who uses it to make a verifiable presentation to some relying party in a way that preserves their privacy. Those are solid use cases. But the trade use case differs significantly.

An example: there’s no way an exporter in Australia would make a verifiable presentation to China customs. Instead the exporter needs to be able to link their GS1 shipment identifier, itself part of a chain, and their verifiable Australia Business Number to their DID. Then the exporter issues a commercial invoice as a VC. The importer gets the VC and passes it to their broker who includes it with the customs import declaration. Then China customs verifies the invoice VC, resolves the issuer DID to find the vABN, and confirms that the subject did of the vABN VC and the GS1 VC is the same as the issuer DID of the invoice VC.

There may be other technical ways to achieve this traversal of “verifiable linked data” (IETF ACDC perhaps) but a more general method of verifying what is in effect a trust graph is needed. It requires a method to link VCs in a way that generic verification software can check multiple VCs that will be issued by completely unrelated organizations with no business relationship, all to prove that the data being presented has multiple roots of trust.

In this session, Steve Capell from Pyx, lead author of the UN Transparency Protocol at UNECE and Phil Archer from GS1, who co-chairs the Verifiable Credentials Working Group with Brent Zundel, explore what's needed for trade. They will be joined by Ivan Marin from the Global Legal Entity Identifier Foundation (GLEIF).

A group of us have been working on the Accessibility Compat Data project, with the goal of creating a machine-readable dataset that tracks the interoperability of web features across browsers and screen readers, and integrating that dataset into existing developer resources like MDN. We've had support from Mozilla, The A11Y Project, the Web DX CG, Open Web Docs, WPT and more. Whether it's your first time hearing about this work, or you've been tracking the work, this is an opportunity to be updated on what we've been doing.

The ARIA WG will be discussing a number of accessibility interoperability initiatives, including ACD, however if you're not part of the ARIA WG or can't make that session and want to be clued into this specific work, this is the session for you.

Users who don't have a strong connection to U.S. measurement, date formatting, and other similar conventions use software with U.S. English as the UI language. This is a problem when the users, for example, don't want to see temperatures in Fahrenheit or accidentally book tickets or accommodation for the wrong days due to site-supplied date pickers (as opposed to browser-provided <input type=date>) putting Sunday in the first column when presenting a month as a grid.

We believe this problem can be addressed by the browser prepending a language tag with a special region code (provisionally en-ZZ, "English of Unknown Region") to the language preference list when en-US would otherwise be the first item on the list and the browser determines that standard measures would work better for the user.

For more information, please see our explainer.

The proposal has previously also been presented and discussed at TC39 TG2.

Possible session co-chair (if registered for TPAC): @hsivonen

There’s been a lot of discussion recently about ways that HTML element references (IDREFs) could be augmented to improve both DX and end-user experience - particularly with respect to accessibility - on the platform. A range of solutions (and problems) have been posited and proposed - but whilst there’s broad acknowledgement that there’s room for improvement, we don’t have consensus as a community on exactly what the challenges are, nor on the relative merits of various solutions that have been proposed.

Major points of contention include:

• The nature of the DX problem or problems.

• The costs and benefits of different solutions that have been proposed.

• What research is needed to clarify the above, and who is best placed to carry it out.

Discussion has been happening mainly in a WHATWG thread and in a recent Accessible Platform Architectures (APA) WG call. However, two key documents to familiarise yourself with, if you are interested in attending, are:

• The explainer for the proposals

• Alice's summary of the discussion and concerns

This session aims to bring together the proposers and proponents, and accessibility people, in order to:

• Come to agreement on how the problem could be clearly defined.

• Dig into more details of the costs that accessibility people are concerned about - and how those costs may be more clearly articulated.

• Arrive at some concrete actions (user research, clarification of proposals, prototyping) that could move the conversation forward by providing further data.

Digital identities are crucial building blocks for our modern digital infrastructure. Over the last years, numerous governmental initiatives have been launched to establish certified digital identities, which are supposed to provide strong identification guarantees of their holders for digital processes in governmental as well as private sector applications. As a consequence, there are high security requirements for this type of identity system and all of its components. In this talk, we present relevant threat models on different layers of a system architecture for such a system and discuss potential challenges when composing their results. We thus argue for the necessity of a holistic approach to understand the threats against this type of a system.

Possible additional co-Chair (if registered): @carbeer

How do you show a hyperlink on a web page? Maybe underline it, make it a different color etc. So far so 1990s.

How about an option to show it as a QR Code? Perhaps by just by setting an attribute on the element? You can click it, or you can open the link on another device.

That can help jump from a checkout screen on your laptop to a payment system on your phone or simply sharing content from one device to others. Maybe it's a DID, a GS1 product identifier, a DOI, a vCard, a location, a Verifiable Credential.

And if the QR Code is generated in real time in the browser, it's possible to do things like add one-time tokens and other security features that cannot be effectively added in printed symbols.

This session is an early exploration of the idea. Please come and share your thoughts.

Questions, suggestions or concerns to the work of the SVG WG or compatibility/interoperability of SVG2? Let's meet and discuss.

In this session we would like to spend time to have an open conversation about the complexities and opportunities for allowing window transparency for web content (in both browsers and web renderers more generally). The web is the most versatile UI framework of all time, but is currently walled within a set of rectangles. The possibilities when breaking out of this are endless (especially as we move to new computing platforms), but there are real and critical challenges that must be addressed. We hope this session can help start to collate a cohesive list of these considerations, as well as start to work towards a set of guidelines that can help guide future approaches for browser developers.

The ARIA-AT program and Community Group validates how assistive technologies and browsers work together by running automated and manual tests on real screen readers and comparing the results to expected behaviors. This lets us measure interoperability across APG design patterns and, more recently, ARIA and HTML features. We’ll walk through recent improvements in the program, along with lingering challenges, and have an open discussion about what the future of the program could look like.

In this session, we are going to share the recent progress on the development of the Servo project, future direction choices, as well as the challenges we are facing as an immature UA implementation.

Join the Chrome and Firefox teams to see significant advancements in the Web Speech API, developed in response to community feedback. The session will feature demos of powerful new capabilities now shipping in Chrome, including on--device speech recognition, contextual biasing, and MediaStreamTrack input support. This session is an interactive forum to discuss the API's current state and brainstorm its future. Come provide feedback and help define the next generation of improvements for web-based speech interaction.

Slides: https://docs.google.com/presentation/d/1zRSgSCJ32FtvwtxbVaStyxt6ZERlKL8obApqwBHRWGU

The Web of Things (WoT) WG/IG will run a PlugFest from 09-11 November. This breakout session will show the results of the PlugFest including live demos from different participants.

You will learn how WoT counters the fragmentation of the Internet of Things (IoT) by using and extending existing, standardized Web technologies. By providing standardized metadata and other re-usable technological building blocks, W3C WoT enables easy integration across IoT platforms and application domains.

We propose the international standardization of the AMT Protocol (Japanese name: AMATELUS) — a Lean4-verified protocol designed to solve the three critical challenges encountered when introducing DIDs and VCs into Japanese municipal systems.
These challenges are not unique to Japan; municipalities and enterprises around the world likely face the same issues.

Three Core Challenges in Implementing DIDs and VCs for Smart Cities

1. Traceability Problem – Resolving DID Documents on blockchains or IPFS makes DIDs inherently traceable.
2. Over-Disclosure Problem – Selective disclosure in VCs still requires revealing excessive personal information and enables cross-linking of identities.
3. Auditability Problem – Using ZKPs can conceal DIDs and personal data but makes legitimate governmental audits impossible.

To move beyond proof-of-concept and enable real-world deployment of decentralized identity systems,
we present the AMT Protocol, a concrete and verifiable solution integrating decentralized identity, privacy preservation, and public accountability.
A detailed Blueprint and formal verification in Lean4 are already publicly available.

Web site: https://amatelus.com
DID method PR: https://github.com/w3c/did-extensions/pull/639
Lean4 code (Japanese): https://github.com/amatelus/amatelus

A discussion about Accessibility Roles and Responsibilities Mapping (ARRM) and its role in helping accessibility evaluation.

Slack

The Credential Management API has rapidly evolved into a critical component of identity on the web. From enabling seamless passkey experiences via WebAuthn to integrating federated identity flows through FedCM, facilitating SMS OTPs with WebOTP, and now facilitating the exchange of verifiable digital credentials via the Digital Credentials API, its scope continues to expand. This proliferation of capabilities sparks a critical discussion: how can these individual strengths be synergized for richer, more secure, and user-friendly identity experiences?

This session aims to explore three key scenarios: first, the concept of multi-type credential for sign-in requests, for example allowing a single API call to solicit a passkey, a password or a federated identity, second, a multi-type credential for identity attributes, for example allowing a single API call to solicit either a federated assertion or a digital credential based on the application's needs; and third, the potential for a method that combines identity claim acquisition (e.g., name and verified email via federation) with simultaneous passkey creation, streamlining initial sign-up and subsequent passwordless authentication.

Several Web standards rely on cryptographic algorithms to ensure security and privacy properties.
However, choosing the right algorithm and configuring it correctly is often challenging for developers who are not cryptography experts. The number of available algorithms, evolving standards, and frequent deprecations make it difficult to identify secure and interoperable solutions.

SING Interest Group proposes a session on the use of cryptography to present an ongoing draft addressing this topic.
This draft document aims to provide a clear and practical overview of standardized cryptographic algorithms and their recommended usage in various contexts. It offers guidelines on when and how to use specific algorithms, parameter choices, and common pitfalls to avoid — promoting a consistent, standards-based, and secure use of cryptography across web technologies.

You can find the most recent editor's draft at https://w3c.github.io/security-guidelines-cryptography/.

The purpose of this session is to present the current version of the document and discuss its content, by collecting feedback from participants and discussing some open points that require further analysis or decisions.

2023's breakouts had a discussion on alternatives to customized built-ins.

A sketch of a proposal came out around this time: customised attributes. https://github.com/WICG/webcomponents/issues/1029

I'd like to set some time to discuss this idea, the merits, complexities, and discuss whether or not this solves problems for developers without too much complexity for the platform.

Users from around the world often see numerical amounts on web pages either in unfamiliar units, or with unfamiliar punctuation denoting large or decimal amounts which can be hard to interpret, or worse, easily misinterpreted. If publishers had a mechanism to explicitly denote these numerical amounts and their units if any, then browsers could offer a privacy-respecting user-interface to display these amounts to the user according to their local units and punctuation preferences.

Background reading:

• Mozilla has written up an Amount element explainer with further details for consideration.
• There is also a separate but related TC39 Amount object proposal working on similar use-cases.
• Firefox shipped an address bar unit conversion UI recently.

This session will focus on how to involve university students in implementation of the web platform (for example, browser engines), using a recent experience from the University of Bergen (UiB) in Norway as a starting point. At UiB, students have worked on real-world contributions to several ECMAScript proposals, including implementation work in JavaScript engines. Some of these projects were learning exercises, and some resulted in merged patches.

We want to explore how universities can establish similar collaborations with W3C and other relevant SDOs:

• How does one connect students with standards groups?
• How much involvement is needed from mentors, and how do we make that sustainable?
• What are the incentives for standards groups and universities to participate?
• What kind of contributions can we expect students to make (for example, spec development, tests, implementation), and how scalable this could be?
• What kind of course structure supports this kind of work?

Slides

Isolated contexts (and their implementation in Chrome, Isolated Web Apps) have been launched In ChromeOS since 2024, together with a few powerful APIs:

• Direct Sockets
• Controlled Frame
• Multiscreen Capture
• Web Smart Cards

The objective of this session is to provide a comprehensive overview of the platform's current state and present our vision for its future development.

https://github.com/w3c/webappsec-csp/issues/736
The energy in the room when we discussed after my presentation was 'CSP was never built for this'. So perhaps now is a great time to think ahead of what CSP will not do and figure out what a good mechanism could look like to stop such attacks (I have suggestions).

Together with researchers at CISPA, the Chrome Permissions team ran a study on how websites prepare users for permission prompts, which was published at ACM CHI 2025. During this breakout, I'd like to present some of our findings and then have a discussion about the following aspects:

• The importance of providing context to users making security and privacy decisions on websites
• The role of so-called pre-prompts, given that other platforms recommend them [1,2]
• whether or not there is anything we want to (and can) do to address annoyance from misused pre-prompts

Please feel free to suggest additional aspects that could fit this breakout in the comments.

This breakout session will explore the intersection of Artificial Intelligence (AI) Agents and Web in W3C, focusing on whether and how browsers should evolve to support AI-driven applications, computation, and agent interactions.
The discussion will cover the ongoing work within the WebML WG/CG, emerging AI-related APIs, and the potential role of browsers as intelligent execution and interaction platforms in the age of large language models (LLMs) and AI agents.

Many jurisdictions have enacted (or are currently enacting) regulations on age-based restrictions to online content. These regulations, and their requirements, can have significant effects on technical architectures and end users. This is a complicated technopolicy issue that is moving fast–although the policy debates indicate a lack of understanding about available technologies, their capabilities and their limitations. This breakout seeks to bring together people with interest and insights about this problem, in the hopes of advancing the discussion in a positive direction. The recent IAB/W3C workshop provides a starting point, and will be used to shape the discussion. However, it is clear that more work needs to be done to develop, explore, and analyze different technical approaches to this problem space. Please join us to learn and help identify better solutions in this space.

Customizing the navigation experience, whether same-document or cross-document, is a theme that is associated with many web features, especially newer ones like view transitions.

Several new features that are being worked on address this theme directly, by making more parts of the navigation experience declarative.

• Declaratively streaming HTML
• Respond to document URL changes & navigations directly in CSS
• Better support for navigational gestures
• Two-phase view transitions

Participants will receive an overview of the use cases, motivations, plans and challenges behind working on this theme, some shallow dive into each of the features, and opportunities for follow up.

WCAG-EM is a process for deciding whether a website conform to WCAG, the Web Content Accessibility Guidelines, even if that website is very large. It is currently being updated (to WCAG-EM 2. In this breakout, I'd like to:

• give an overview of what we're updating and solicit feedback
• get input on making evaluation more effective
• get input on making evaluation more trustworthy

Slides: https://hidde.github.io/b6-logius/20251111-tpac-wcag-em/

Slack: agwg-wcag-em

Originator Profile (OP) has published its technical specifications, architecture overview, and Originator Profile Blueprints series documents. Join us to see how the current version works and discuss how we manage and operate this framework to combat the flood of malicious information on the internet. Please come and provide feedback or discuss with us.
We would also like to introduce the progress of implementing the framework to the Japanese media industry and local governments.

This session is an opportunity to engage with the AB to discuss frictions and difficulties that may exist within the current Process document and engage in a conversation about potential changes.

As required by the Security and Privacy Questionnaire for the Horizontal Review, when writing security consideration sections that reference RFC 3552, a threat model must be created and the specific elements exported to the Security Consideration sections (but this also applies to privacy, and in general to harms as well).
But how can threat modeling be done in a structured way in practice?

The Threat Modeling Guide answers this question in a practical way and includes a Threat Model for the Web to speed up the work.

Several times over the years, ACs have discussed whether there would be value in "another TPAC" but this is challenging for a whole lot of practical reasons. But what if it were simpler? What if it basically already existed?

The Web Engines Hackfest has been held annually since 2009, hosted by Igalia in A Coruña, Galicia, Spain. For several years now we have hosted it at palexco a large conference venue. It is "shaped" similarly to TPAC in many ways, with talks and breakout sessions on all things web, and attendees from all of the major browser vendors (and numerous smaller ones!).

It would be interesting to discuss partnership/promotion and collaboration on the Hackfest's ability to play this role.

The advent of Passkeys and Face ID on the web has been a huge boost to security and simplicity for verifying returning users.

However, there remain the questions of:

1. How can an institution can confirm the authentic identity of an end user when registering these credentials?
2. What would happen if a user lost their passkey-bearing device?
3. How could a web-based, shared user device handle multiple identities without requiring those people to hold devices.

The established answer is biometric ID verification where a facial comparison of an identity document and selfie image are made, in addition to liveness checks to prevent presentation and deepfake injection attacks. Many offerings exist today, including from established tech firms such as Amazon and Microsoft.

The Web platform is well-positioned to perform these sorts of ID check ceremonies since it doesn't require heavy apps to be downloaded for what is usually a one-time task, and key tenets of the platform are to provide an accessible, democratised and powerful way to interact with digital services - important to avoid "digital deserts" and to enable people in all geographies, of any demographic, to interact with civic services, financial institutions and so on.

Today, the best experience is afforded to users of native apps due to the availability of several features that the Web platform doesn't have any, or uniform API support for.

Here are some examples we could improve on:

1. Reading the current lighting environment via ambient light or EXIF data - useful for guiding users to submit good quality imagery for checking.
2. Boosting screen brightness, if needed, for the duration of the image capture.
3. Detecting the presence of and accessing any infrared cameras.

The mission of the Web-based Digital Twins for Smart Cities Interest Group
(SCIG) is working on the following:

• identify and document use cases and requirements that W3C specifications need to meet to support various services within Smart Cities,
• obtain feedback from all stakeholders on the usage of Web technologies for those services,
• gather expert input on important features for those services based on the Web technology,
• and provide a forum for technical and business discussions related to those services.

You will learn the current best practices of cutting-edge standards for smart
cities around possible framework and vocabulary ontologies, and then see how Web standards could possibly counter the fragmentation of existing smart city
approaches.

Convertible devices (Chromebooks, Surfaces, and tablets, to name a few) are devices that can switch from a touch-first mode into a more traditional desktop mode. Today, they're not well represented in web standards: the Form Factor client hint neither includes it nor is there another way to query for it, there's no listener event for form factor changes, and key user experience flows that can change depending on the form factor (like how window.open works) can't be queried for.

I'd like for this to be a brainstorming session on the different items, like mentioned above, a developer may need to know and react to for a convertible device to provide users a better experience on those devices.

The Agent Network Protocol (ANP) is an open-source communication protocol for AI Agents, aiming to become the “HTTP of the Agentic Web era.” Its ultimate vision is to build an efficient, secure, and open network for agent collaboration. ANP seeks to break down data and agent silos by adopting open, interoperable standards that enable cross-platform identity authentication, discovery, and interaction between agents.

Built upon W3C standards such as DID (Decentralized Identifiers), Verifiable Credentials, and JSON-LD, ANP defines how agents publish their identities, describe their capabilities, and establish secure communication channels for data exchange and task collaboration.

This session will introduce the core design principles of ANP and explain how it differs from emerging protocols such as A2A (Google) and MCP (Anthropic).

ANP Open Source Repository:
https://github.com/agent-network-protocol/AgentNetworkProtocol

The phrase “Open Web” has served as a rallying cry for those who champion the benefits of the Web as we know it to humanity. However, there are subtle (and not-so-subtle) distinctions in what it means depending on who you talk to: some believe it to be a Web where all content is available no matter the purpose; others focus on “Open Web” in relation to the advertising market; yet others distinguish between open to humans-using-browsers vs. other clients.

At the same time, large parts of the Web have always been behind logins and paywalls: the so-called “deep Web”. Furthermore, it’s important to acknowledge that the reason that many parts of the Web have been free to access because they are advertising-supported – along with all of the concurrent privacy harms.

While there may not be strong agreement on what the Open Web is, it’s widely held that it is under more threat than ever, thanks to the emergence of AI. Content authors, publishers, and hosters may have been accepting of the bargain they got from search crawlers: let us access your content and you will get traffic from search results. They are much more reticent about exposing their content when it has no such quid pro quo.

As a result, blocking unknown or unwanted crawlers has become more common, and the Web Bot Auth effort is in the process of being chartered to enable known bots to cryptographically authenticate themselves – with the implication that those clients that don’t may be blocked. There are also proposals emerging for payment protocols specifically targeted at not only crawlers, but also bots and agents – and maybe even for browser micropayments.

There are also emerging concerns that AI will put gatekeeper platforms in the position to drive further concentration: to pressure publishers to submit content to them directly rather than taking on the cost of hosting content themselves, thereby further foreclosing what was previously open content.

These changes have led to questions about the future of the Open Web – whether we’ll have one, and what it will look like. A less open Web is one where it is more difficult to introduce new non-browser agents or run services that don’t have immediate financial advantage for sites. One where more data is locked up indiscriminately.

This session will explore questions in this area, such as:

• Is there a useful definition for the “Open Web”? Or is it better to have more specific goals?
• Are there useful metrics for the Open Web that can be tracked?
• What purposes do sites have for not being open?
• Is there more than one economic model that promotes the Open Web?
• How is privileged access for search engine crawlers changing?
• What impacts on the Open Web do we see from AI and “agentic” clients?
• Are there best practices for sites and services that could help mitigate those impacts?
• Are there standards activities that could help mitigate those impacts?

For notes from both meetings, see:
https://docs.google.com/document/d/1WaXDfwPP6olY-UVQxDZKNkUyqvmHt-u4kREJW4ys6ms/edit?usp=sharing

A discussion on geolocation and privacy.

Approximate Geolocation proposes to give sites the ability to request obfuscated position estimates. Obfuscation protects user privacy by making it more difficult for sites to recover the user's true location. We'll review IETF GEOPRIV recommendations for location obfuscation and discuss how obfuscation was implemented for Mozilla's Geode add-on.

We'll recap the history of geolocation on the web platform. What were the influences that resulted in Geolocation API's privacy model? How did the Geofencing and Geolocation Sensor proposals approach location privacy? How do current proposals address privacy concerns?

Open discussion on the future of location privacy on the web.

The Cybernetic Avatar is a concept of a networked embodiment that digitally extends and transmits human physical, perceptual, and cognitive capabilities through the Internet.

It envisions a world where people can project their presence, perception, and action beyond the limits of body, space, and time by connecting to digital or robotic embodiments.
This breakout session will share the current vision and motivation behind the emerging Cybernetic Avatar Community Group (currently in formation).

We aim to discuss how the concept of the Cybernetic Avatar could relate to existing or future Web standards, and how the W3C community might help define its role within the broader Internet ecosystem.
Together, we will consider how human embodiment, communication, and agency may evolve through connected systems, and how open, ethical, and inclusive frameworks could support this transformation.

We are currently in the process of forming the Cybernetic Avatar Community Group, and this session serves as an open discussion for anyone interested — please join us!
(The introductory video for the Cybernetic Avatar initiative is available here. - https://www.youtube.com/watch?v=u0NjMfUod10)

The WebRTC APIs have long enabled sending and receiving realtime media peer-to-peer with a streamlined control interface, but with limited ability to tune how media is encoded and interacts with the network. While APIs such as WebCodecs have begun to allow users low-level access to the browser's built-in encoders and decoders, there is still no API to allow similar levels of access to the low-latency peer-to-peer network transports like those used within an RTCPeerConnection.

The RtcTransport API aims to enable applications to directly utilize peer-to-peer datagram based transport for realtime media, controlling the details of congestion control and allowing arbitrary media encodings and formats. The current proposal is an evolution of the RTP-focussed transport discussed in a breakout session at TPAC 2024.

In the first episode we focused on high-level threats related to the Formal Objection received for the addition of the Digital Credentials API.

In the second episode, we discussed the presentation side, in particular how Digital Credentials API can differentiate between different presentation approaches (e.g., custom schemes and QR Codes).

In this third episode, we will discuss the new layered heart model in the presentation, and on how to derive the security consideration sections, then we'll prioritize threats - e.g., of Malicious Wallets during issuance or othres - to propose mitigations.

This session will provide an update on the approach and progress for the W3C Accessibility Guidelines (WCAG) 3.

W3C Accessibility Guidelines (WCAG) 3.0 is a successor to Web Content Accessibility Guidelines 2.2 and previous versions. Changing technology and changing needs of people with disabilities require a new model to address content accessibility more comprehensively.

WCAG 3.0 will use a model that allows it to:

• address more disability needs than WCAG 2,
• incorporate publishing requirements and emerging technologies such as web XR (augmented, virtual, and mixed reality) and voice input,
• facilitate maintenance, so that the new model will be more enduring over time as technologies evolve, and
• include additional information about the ways web technologies need to work with authoring tools, user agents, and assistive technologies.

Web platform APIs are typically specified having web browsers as their main target. However, there is a large set of JavaScript runtimes that benefit from having a common API surface with the web platform.

WinterTC is a new Ecma Technical Committee focused on the needs of such runtimes, particularly in the server side. This TC is an evolution of the previous WinterCG W3C Community Group, to focus on standardizing a minimum subset of the web platform APIs that all such runtimes would support (the WinterTC Minimum Common API).

Aside from publishing its own standards, however, WinterTC also aims to propose changes to existing W3C and WHATWG standards to better support the needs of server-side runtimes. For example, in browsers, origins are a fundamental security primitive, and it makes sense that, for example, the fetch() API has cross-origin restrictions. But since server-side runtimes don't have this security primitive, these restrictions are unnecessary in such environments, which is why they all willingly violate the spec. WinterTC aims to fix this in the web standards by adding conformance modes for server-side runtimes.

The World Wide Web is at a critical juncture, facing increasing centralization and the loss of its original decentralized philosophy. This breakout session will propose a new approach to web mapping that not only addresses the need for a modern, interoperable map standard, but also serves as a model for shifting the entire Web's paradigm from centralization back to a self-organizing, user-centric model.

We will introduce the Hyper-Layering Architecture (HLA), a philosophy that has been under development since 1996 and submitted to SVGWG in 2011. Unlike traditional approaches that rely on a single, centralized service or data format, HLA leverages existing Web principles to enable a decentralized, flexible, and powerful web mapping system. This session is in scope for a breakout as it addresses core web architectural principles (decentralization, user control) described in the W3C's Ethical Web Principles and Vision for W3C, and their application to a new, native content type (maps).

We understand and respect the work of the Maps in HTML Community Group, with whom we have been in discussion for many years. However, we also believe there remains a non-negligible philosophical gap between our two approaches.

Brief overview of the Accessible Platform Architectures Accessibility Maturity Model Group Note. We will give of condensed history of its inception, what it means to you, why it’s important, how to use it, and what our future plans are for further development.

Various browser implementers have announced plans to ship agentic browsing experiences, i.e. AI-powered features that take action on websites on the user's behalf. (1, 2, 3, 4, 5, 6, 7, etc.)

These exciting new capabilities also come with new security challenges through the exposure of LLMs to untrusted web content and their ability to access the user's private information and take action on their behalf (a case of lethal trifecta).

We'll examine how the new possibility of prompt injected user agents impacts the Web's security model and discuss how browser and agent implementers, web developers and other ecosystem participants can design a safe agentic browsing experience for the Web Platform.

Our project to revamp the Community Group program includes improvements to communications about CG specifications. In this breakout session we will discuss our current thinking about the CG specification lifecycle.

An important part of improved communication includes clearer representation of status information and greater stylistics distinctions between CG specifications and Rec-track deliverables. We will share mockups and invite feedback.

We will also demo tooling for helping editors gather data that will be used to convey status information in specifications, and discuss ideas for maintenance of that data.

The W3C Accessibility at the Edge Community Group is finalizing for imminent
release it's final report addressing the trade-offs and benefits of applying
dynamic accessibility
remediations to web content. Today's typical web page is a complex blend
of multiple original sources, yielding experiences that work well for some
users but fail for others, leaving many websites and online applications
inaccessible to people with disabilities. In development since early 2023, the
report titled: Accessibility Capabilities: Post-Source Code and Content features cross-references to WCAG throughout, because WCAG remains the valid yardstick whether applied in-source or post-source.

Brainstorm ways to improve the effectiveness of the AC, as a community and in its role advising and overseeing W3C activities.

This session will target AC Reps in particular.

(@frivoal is proposing this session, but others will chair it.)

At the W3C’s Advisory Committee meeting in Hiroshima, Japan, last year, Mitsuo Ochi, the president of Hiroshima University, challenged W3C to “take proactive actions towards realizing a peaceful future.”

Tim Engelhardt from the UN Office of the High Commissioner of Human Rights, while acknowledging the reference to human rights in the Ethical Web Principles, likewise challenged W3C to put people and their rights at the center of processes, saying “standard setting organizations and their participants, should commit to the application of human rights, using human rights methodologies”.

More recently, the UN OHCHR has run a series of workshops involving standards bodies, one of which I did a write-up of here: https://lists.w3.org/Archives/Member/w3c-archive/2025Jul/att-0280/Workshop_Report__Advancing_Human_Rights-Aligned_Standard-Setting.pdf.

We have also discussed this topic in the Advisory Board.

Temper is a programming language that translates to all the other languages and which aims to simplify standards development.
The goal of the tool is to make it easier for different language communities (data scientists/pythonistas, web devs/javascripters, backenders) to identify common problems and share solutions.

Slides

With it, you can write a library once and get libraries in all the languages widely used in OSS software. (Traditional compiler methods based, not AI)

Some standards efforts have significant components that are not dependent on the stack:

• L10N/I18N standards are about human languages and cultures, not the tech stack that is composing strings to present. Having ubiquitously available libraries like ICU & grapheme clustering would be good.
• Representations of currencies
• How to derive "safe" HTML from untrusted HTML is not about the tech stack.
• Arithmetic about color
• Parsing and unparsing URLs
• How to encode and decode records received over the web, validate, and fill in missing info.

Perhaps these or similar standards would benefit from providing a partial reference implementation, data files, and/or test suites to developers, tool authors, and horizontally to other W3C groups.

For standards driven mostly by non-software-engineer domain experts, the hope is that a tool like this might allow building reference implementations for many programming language communities with a single engineering point of contact lowering coordination overhead when changes to a standard are needed.

Beyond pure web apps, WebViews are essential for cross-platform development. Frameworks like Cordova, React Native, Electron, Tauri, and many others prove that. Other relevant use cases are: MiniApps, whose SuperApps implement dedicated embedded web engines for content rendering; EPUB readers; and infotainment systems. These domain-specific use cases sometimes do not require a full-fledged WebView with a full implementation of Web standards. Indeed, these platforms use hybrid technologies that are inspired by Web standards (e.g., restricted CSS modules, HTML subsets, and JavaScript APIs). Occasionally non standard features are added and can create fragmentation.

This breakout session aims to discuss the design and use of modular web engines, considering the concrete constraints of the application scenario and the benefits for potential new use cases, including the homogeneous implementation of cross-platform MiniApps, WoT apps, and AI agents. These hybrid platforms could benefit from these modular standards-based application profiles (i.e., subsets of current specifications) to reduce the size of engines, thereby increasing efficiency while maintaining compatibility with existing standards.

Some questions to be addressed during the session:

• How these modular Web engines support the growth of the Web without bringing fragmentation?
• How do new web engines define their roadmap and development priorities?
• Could the existing Web DevX tools (e.g., WPT, CanIUse, CanIWebView, Web-Features, …) support the development of new engines for these purposes?

The web platform's evolution is often faster than developer practices. This lag creates a two-part problem that slows the adoption of modern APIs and leaves unnecessary bloat on the web:

1. The "sticky polyfill" problem: A feature (e.g., IntersectionObserver) becomes Baseline, but developers continue to ship unnecessary polyfills and fallbacks for it, sometimes for years. The IntersectionObserver polyfill, for example, still gets over 2.1 million weekly downloads despite the feature being Baseline for over 6.5 years.

2. The "reluctant adoption" problem: A new, powerful feature (e.g., the Scheduler API) is available, but because it is not yet Baseline, developers may be reluctant to use it, even when robust polyfills and fallback strategies exist. Those strategies should be easily discoverable to developers and integrated with their tools.

Both problems hold back the web and share a common root: the lack of a structured, machine-readable data source that maps "old ways" (specific polyfill packages, legacy patterns) to their "new way" modern API counterparts.

This session proposes we create one.

If tooling (IDEs, linters, framework CLIs, browser DevTools) had a "Rosetta Stone" dataset, it could, for example:

• Detect the IntersectionObserver polyfill, query this dataset, see the native API is Baseline, and confidently recommend removing the polyfill.
• See a use case for the Scheduler API, query the dataset, and suggest a progressive enhancement strategy that safely encourages immediate adoption.

There are a number of followups for customizable select that I'd like to gauge interest in and get feedback on:

• https://github.com/whatwg/html/issues/8189
• https://github.com/whatwg/html/issues/11477
• https://github.com/whatwg/html/issues/11535

There are also other proposals related to having a text filter for a select element, as well as making <input type=text list=datalist> more customizable:

• https://github.com/whatwg/html/issues/11288
• https://github.com/openui/open-ui/issues/847
• https://open-ui.org/components/combobox.explainer/
• https://github.com/openui/open-ui/issues/1273

The Ministry of Digital Affairs (moda) of Taiwan has developed a Digital Identity Wallet infrastructure based on W3C standards for Decentralized Identifiers (DID) and Verifiable Credentials (VC), enabling an open and interoperable ecosystem: https://wallet.gov.tw/

This session will share our key achievements and learnings from the past year, and highlight related regional collaboration efforts.

Ecma is a standards body responsible for far more than specifying JavaScript™. There are currently 17⅔ active technical committees†, and historically 56 total. Some of these technical committees focus on hardware, acoustics, the environment, and even consumer safety. Closer to W3C home, work areas include programming languages (Dart, C#, Eiffel) and a variety of software-related topics ranging from supply chain security to Office Open XML formats. In this breakout session, we’ll explore these together and dive a little deeper on whichever the attendees find most interesting.

I proposed this breakout session last year but wasn't able to gather the information I wanted to provide. This year I'll be able to show up with a deeper knowledge of history and, after an introduction, prompt participants for which topics they wish to further discuss.

† The ⅔ will absolutely make sense

Verifying control of an email address is a frequent activity on the web today and is used both to prove the user has provided a valid email address, and as a means of authenticating the user when returning to an application.

Verification is performed by either:

• Sending the user a link they click on or a verification code. This requires the user to switch from the application they are using to their email address and having to wait for the email arrive, and then perform the verification action. This friction often causes drop off in users completing the task. There are privacy implications as the email transmission informs the mail service the applications the user is using and when they used them.
• The user logs in with a social login provider such as Apple or Google that provide a verified email address. This requires the application to have set up a relationship with each social provider, and the user to be using one of those services and wanting to share the additional profile information that is also provided in the OpenID Connect flow.

The Email Verification Protocol enables a web application to obtain a verified email address without sending an email, and without the user leaving the web page they are on. To enable the functionality, the mail domain delegates email verification to an issuer that has authentication cookies for the user. When the user provides an email to the HTML form field, the browser calls the issuer passing authentication cookies, the issuer returns a token, which the browser verifies and updates and provides to the web application. The web application then verifies the token and has a verified email address for the user.

User privacy is enhanced as the issuer does not learn which web application is making the request as the request is mediated by the browser.

https://github.com/WICG/email-verification-protocol

The bulk of today’s web platform design is done in-house at major browser vendors. This deprives the Web of vital diversity of perspective and naturally favors work with visible short-term impact over the exploratory, bigger picture R&D needed to tackle deeper architectural issues.

For most other web stakeholders, the standards process remains an intimidating black box — so rife with misconceptions and barriers to entry that spending millions on workarounds can seem easier than fixing shortcomings at the source.

And for most other web standards designers, it is a labor of love, disincentivized by employers or as an unpaid side project.
The web platform is one of the most impactful products in the world.
Shaping its evolution requires a rare combination of deep, broad, and interdisciplinary expertise. When the few who can do it well are driven away from it in order to make ends meet, the entire Web loses.

These issues are intertwined. To make independent standards work sustainable, we need to expand the pool of available funding — and the only lasting way to do that is by helping more organizations see web platform design as a path to solving their own problems.

Prefetching can significantly improve web performance by loading resources before a user navigates to them, but doing so across different origins or sites can harm user privacy. Directly prefetching from a third-party server can leak a user's IP address and browsing context.

The Prefetch spec states a need for IP anonymization and handwaves over how it’s achieved, leaving it implementation-defined [1]. Let’s look at a couple proposals of how this works in the browser, with a browser-provided proxy [2] and a proposal for website-provided proxies [3].

Finally, we will discuss the path to enable private cross-origin/site prefetch across browsers. Open discussion of privacy and security goals, threat models, and future work in implementation and standardization.

Slides for this meeting are available at: https://docs.google.com/presentation/d/1fBEJXtRe7qoJA5ISNYzAEE6gRYiJ9lOhDu9hdRYlCxM/edit?usp=sharing

Minutes for this meeting are available at: https://docs.google.com/document/d/1ldeQe351vqxMM3IFijEM5Myc9CJ8_EnFGB1EOgSyeys/edit?tab=t.0

The concept of an "agentic web," where AI agents act on a user's behalf, is a growing topic of discussion. Currently, these agents often rely on brittle inference, parsing visual labels or class names to understand a website's functionality. This model is fragile; simple A/B tests or site redesigns can break an agent, leading to high task failure rates. Keeping in mind that for many tasks the acceptable failure rate is 0. This model can also be compute-expensive, as many implementations resolve ambiguities using a combination of DOM Tree and pixel scraping, greatly limiting the performance of agents who might have resource constrained (i.e. on-device) models.

For human-facing assistive technologies, ARIA closed gaps in semantic HTML, creating a more robust experience for users of AT. Now, we face a similar question for machines.

This session is a general discussion to explore whether our existing semantic toolkit is sufficient for this potential use case.

• Is ARIA, which is designed for human accessibility, the right tool to serve machine agents? An interesting point of reference is this FAQ from ChatGPT which states "ChatGPT Atlas uses ARIA tags—the same labels and roles that support screen readers—to interpret page structure and interactive elements."
• What happens when we conflate these two distinct purposes?
• More importantly, are there semantic needs for agents that have no human-facing equivalent?

Consider hints that could improve agent reliability and safety, such as:

• Explicitly flagging a button as a destructive action (e.g., distinguishing "Archive" from "Delete Permanently").
• Identifying page content as User-Generated Content (UGC) to allow agents to apply extra safeguards.
• Signaling transient states, like logged-in vs. logged-out status, to help an agent plan a task.

This session is not about a specific proposal. It's about the core problem. Does ARIA already solve for all the hints a machine might need, or should we be considering an additional semantic layer for machines at all?

Let's come together to discuss the problem, the risks of both action and inaction, and the potential paths forwards.

Additional co-chair (if registered): @chrishtr

The web is critical infrastructure, but its environmental and social impacts are growing: energy use, e-waste, and inefficiency at global scale. W3C has championed accessibility and privacy as pillars of a trustworthy web—sustainability needs the same attention.

The Web Sustainability Guidelines (WSG) Community Group initially drafted guidelines, modeled on WCAG, that offers practical, testable steps for reducing the footprint of web technologies. Since then, the Industry group has substantially revised this. We are now seeking a wide review. This breakout will share updates and solicit feedback about implementability, organizational structure, and adoption.

Key discussion points:

• How to incorporate sustainability alongside accessibility and privacy, performance
• How to ensure testability / measure-ability and avoid greenwashing
• Opportunities to highlight integrations with other standards
• Next steps: pilots, adoption paths, and potential W3C involvement

Slack

The Mobile Accessibility Task Force (MATF) produces resources for how to apply the Web Content Accessibility Guidelines (WCAG) to mobile, and makes sure mobile apps are considered in new accessibility guidelines.

The MATF has published its first Group Draft Note of WCAG2Mobile on 6 May 2025, and is currently working towards an update of this draft.

In this TPAC session we want to present the document, explain the challenges, and gather feedback.

Link to presentation: janjaap.com/tpac2025

Minutes: https://www.w3.org/2025/11/11-matf-minutes.html

In this breakout, you'll become acquainted with the Web Developer Experience (WebDX) Community Group and its efforts to formally classify the platform's capabilities into a set of "features" as understood by web developers. You will see how this information is integrated into WPT and the practical value of that integration. You'll also learn how you can support the process as a specification editor and/or test author. Finally, you'll brainstorm opportunities to refine the process in service of fostering more nuanced insights into the state of the platform.

Users of the web are best served by being able to experience it in their native languages. Currently, localization of web content is achieved with a multitude of custom solutions, most of which are unable to express the full depth and breadth of human expressions in all languages. Introducing an easy-to-use but powerful standard localization solution would improve the experience of all users, in particular the vast majority who do not speak English natively.

This session is a continuation of the 2023 breakout session. Since then, the Unicode MessageFormat standard has been published as a part of Unicode Technical Standard #35 and the DOM Localization explainer has been updated. It has also become clear that a web-compatible file format for localization resources needs to be identified as a part of the work towards DOM localization, or a new file format needs to be specified.

Media content metadata is a key enabler for cross-industry service deployment and value creation.

This session will explore practical approaches to improve media metadata interoperability, focusing on industry use cases.

At TPAC 2023, the breakout session titled Facilitating media content distribution across industries discussed the potential and challenges of media interoperability across sectors such as broadcasting and publishing.

Following that discussion, the Media Content Metadata Japanese Community Group (MCM-JP CG) was established. The group gathered case studies, reviewed existing specifications, and verified feasibility using operational metadata.

We will present the outcomes of MCM-JP CG activities with live demonstrations and invite feedback from participants. The session will also identify next steps to expand collaboration and promote practical implementation across industries.

Currently, it is technically possible to apply various legacy credentials to new web standards such as W3C VC, IETF SD-JWT, and ISO mdoc. However, there are no established rules for using these standards in an interoperable or universal manner, not only for National IDs but also for private sector IDs such as Student IDs and Corporate IDs.

We are collaborating with the National Institute of Informatics (NII) to establish standards for Student IDs in Japan based on the ISO/IEC 18013 standard. They are set to create rules regarding how to issue credentials, how to construct the data model, and how to assure and validate the data. We attended a use case demonstration event held by Osaka University this October, where several use cases were accepted by participants from various universities in Japan.

Our goal is to make Student ID interoperable and easy to use, not just in Japan but globally. Therefore, we would like to discuss the following points:

• What are the most common use cases for Student IDs in your country?
• What capabilities would be enabled if Global Student ID Interoperability is achieved?
• What is needed to achieve this, including the prospects for Digital Credentials API?

Device spoofing is a pervasive problem in digital ads, with bots masquerading as user devices, and bad actors spoofing high-value Connected TV inventory. This results in wasted ad spend for advertisers and reduced ad revenue for legitimate publishers. The Privacy Pass protocol, which enables devices to assert their authenticity in a privacy-preserving manner, has been adopted for a digital ads verification use case. This implementation is being standardized within the IAB Tech Lab's Open Measurement SDK to simplify broad adoption by publishers. Using this mechanism, Verifiers (Origins in Privacy Pass), which are typically Traffic Quality / ad verification vendors, will be able to uncover sellers of spoofed inventory and take enforcement actions on them.

We will present the mechanism and how a "positive" and anonymous signal that does not have 100% coverage can be used for fraud detection.

To make better specifications/standards, QA work needs to advance.

Related work:

• W3C QA - core work
• EARL - to facilitate the exchange of test results between Web accessibility evaluation tools in a vendor-neutral and platform-independent format.
• WPT - test suites for some web platform specs.
• Spec Terms - provides classes and properties that can be used to describe any significant unit of information in technical reports.
• Solid QA - connects a bunch of the core QA work (but not actually tied to Solid).
• ...

In the Security Web Application Guidelines Community Group (SWAG CG) we're trying to understand what web platform security best practices exist and which guidance we can give web developers to secure web applications.

The Open Web Docs (OWD) collective has been awarded an investment to write documentation and to conduct research on this matter by the Sovereign Tech Agency. The work OWD is planning to do over the next months is described in this blog post: https://openwebdocs.org/content/posts/stf-investment-2025/

This is an open-ended session proposed to discuss the efforts of SWAG and OWD for security documentation and guidelines for web developers.

WCAG 2.2 includes success criteria related to the visual presentation of text including how text spacing can be used to benefit people with reading disabilities or low vision. In particular:

• 1.4.8 Visual presentation
• 1.4.12 Text spacing

This session will introduce the topic and issues. Specifically:

• What changes are necessary to 1.4.8 and 1.4.12 to accommodate non-Latin scripts?
• What research is available to support changes?
• What other success criteria might include issues related to non-Latin scripts

The strong demand for multimodal interaction capabilities in client-side AI is driving the evolution of next-generation general computing platforms from screen-based and handheld devices to hands-free wearable devices, such as augmented reality glasses and mixed reality visors (head-mounted displays).

Apps (include Web) on such next-gen platforms must be able to:

1. Fully leverage 3D space surrounding the user, moving beyond the limitations of 2D planes, breaking free from window borders.

2. Work with a new OS architecture based on Unified Rendering and Shared Space, in which apps no longer render themselves independently, they can blend in with other apps in the same shared space, and use OS-managed spatial containers instead of old-style windows or browser tabs.

3. Integrate seamlessly with the real-world environment, for example, Apple's recently proposed liquid/frosted glass UI. Instead of using a fixed solid background color or just switching between light and dark modes, the UI dynamically renders a blended material background based on what's behind each part of the interface from the user's perspective, making it clear and readable no matter the lighting or colors in the environment.

4. In addition to conventional 2D panel-based and 3D canvas-based GUIs, apps should be able to include real volumetric 3D content that can be viewed from all angles and measured in real-world units.

5. Whether 2D or 3D, elements must be capable of positioning and transformation along the spatial Z-axis, supporting spatial interaction events to acquire positional and motion data within 3D space, thereby enabling interactions such as dragging, rotation, and scaling.

6. Don't break away from mainstream GUI development ecosystems, keep using the established view components, layout systems, and styling systems from 2D GUI development (for the web, that means HTML/CSS). In most application scenarios, limited 3D development requirements should be embedded within the overarching 2D development approach. For example, 3D container elements should be able to join the X/Y layout system just like 2D elements, while supporting full 3D-engine-style development inside. That means in HTML code you can use different Entities (different geometric Entities, Entities capable of loading 3D model assets, or Entities capable of hosting 2D HTML or particle effects), declare, load and configure materials and textures, and work with EntityTransform and physics engine properties.

Within the existing Immersive Web WG, the WebXR standard, analogous to OpenXR, always take over the binocular display and the entire spatial environment, perform self-contained rendering, and build interactions from scratch, thereby failing to satisfy the aforementioned requirements.

There are some scattered Spatial Web features right now, like Model Element, Immersive Media (Fullscreen API), and Interactive Regions (Hover Effects for Eye-Hand Interactions). They can't systematically meet the needs above, and they still lag far behind native spatial apps.

A systematic solution can only be achieved by equipping existing HTML/CSS and PWA technologies with spatial capabilities, extending the current 2D web standards with a minimal set of new APIs (let's call them the WebSpatial API).

Such an approach would enable the open web to gain entry into the paradigm shift of general computing platforms, and potentially emerge as the optimal application solution for these platforms. This is because both AI OS and MR OS inherently demand vast numbers of apps that are installation-free, on-demand, and disposable - characteristics naturally aligned with the web.

This is a session for everyone to tell stories about weird bugs and behaviors in WebViews. You can also learn how to test your web content in WebViews. We would like to present a few reasons and resources for testing your web content inside WebViews. Then it’s time to share some complex or weird issues you had with WebViews over the years and present some hacky workarounds.

Please bring your stories and issues and share them with us! We maintain the site caniwebview.com and would like to add some examples of when WebViews are doing strange things and provide developers with help to deal with them.

We want to make it easy for you to add features that enhance and deepen the accessibility of the platform on a document level. There are a number of existing and forthcoming to support you in this.

In this session, we’ll share with you some recent updates to several of these resources, as well as details on further enhancements we’re working on. Most importantly, we want to get your feedback, to ensure that the work will help you out.

A full agenda is given separately, but at the highest level, we’ll cover the following, before having a group discussion, so we can answer your questions and get your feedback:

• Recent and planned ease-of-use improvements to the horizontal review process for accessibility - including the need for early help and support, and how we’re making it easier for you to request that.

• What exactly the Accessible Platform Architectures (APA) WG can provide you with in reviews; where that advice comes from; and how you and the review process might contribute to it.

• A new, more concrete, direction for the Framework for Accessibility in the Specification of Technologies (FAST), which aims to reduce the amount of things that come up in review, by supporting you in writing specs that consider, promote, and enhance accessibility from the outset.

Credit to Peter Korn for the ‘building it in vs. bolting it on’ concept.

Chair attendance expectations: @matatk, (in-person), @fredrika11y, (remote), @ananya-ky, (possibly;, in-person)

https://github.com/WICG/PEPC/ (along with specific instantiations of the pattern in proposals like <geolocation> and <install>) suggests a declarative model for capability access, pushing away from a status quo in which developers trigger prompts at will, towards one in which users are more firmly in the drivers' seat.

Historically, the viewport of html documents has always been determined by the browsers frame, being the browser window, browser tab, or browser popup size. The author of the html document can then base their own styling and dimensions based on this size with units like vw and vh which in these situations are deterministic and non-ambiguous.

With the introduction of web extensions, a new type of situation is born in which the author of the html document can, with certain restraints and many issues (which you can read about below) determine and change the size of the viewport by changing the height/width of the html/body elements. Examples are the extension popup and the options page if defined with options_ui.open_in_tab=false.

In an ideal world the document would communicate (in any form, declarative in css for example) its preferred min/ideal/max height/width if in auto size. In which the ideal height/width could also mean "match" the browsers ideal sizing if it sits in between the min/max range. This preference is then incorporated by the browser and either fully or partially respected to render the auto-sized content.

There is some prior art in the CSSWG which discusses the auto-sizing of iframe elements on their parent document. See:
https://github.com/w3c/csswg-drafts/issues/1771 and https://github.com/domenic/cooperatively-sized-iframes
and in the WECG:
https://github.com/w3c/webextensions/issues/692 and https://github.com/w3c/webextensions/issues/436

Some of the techniques currently in use for the auto sizing and some of the proposals to accompany them can be reused/shared for auto-sizing of iframes.

With iframes, security is a concern so the auto-sizing can not be opt-in by default for both host and iframe. A potential way to address this would be adding a "autosize" keyword to the <meta name="viewport"> and an autosize attribute on the iframe.

In line with ongoing efforts to address the harms and threats associated with the deployment of national digital identities, W3C and FBK’s Center for Cybersecurity are collaborating to develop an innovative, high-level threat modeling framework. This model is based on a card deck (similar to the STRIDE Elevation of Privilege game) and integrates the transformative principles of the LEGO® SERIOUS PLAY® methodology to enable comprehensive and participatory threat modeling.

In this breakout session, we will explore how using LEGO® SERIOUS PLAY® for threat modeling can help uncover security, privacy, and human rights risks in digital identity systems, and share insights from the initial validation of our card game.

We will then introduce the card deck itself by showcasing a selection of example cards, built on our previous research and inspired by both the STRIDE Elevation of Privilege game and the LIDDUN-GO deck.

Finally, we will outline our future plans to advance this line of work in the name of safe, human-centric technologies and web standards.

Broken links threaten the long-term integrity and trustworthiness of the Web.
The Link Genetic initiative introduces “LinkID”, a persistent, bidirectional identifier scheme designed to ensure link resilience, metadata preservation, and semantic interoperability across domains and over time.

This session invites W3C members to discuss the feasibility of a new linkid: URI scheme, alignment with existing identifier systems (DOI, ARK, UUID), and next steps toward standardisation.

We plan to:

• Identify potential Working Groups or Community Groups interested in hosting a LinkID proposal.
• Discuss governance, persistence, and interoperability models for resilient linking.
• Outline a roadmap for open-source reference implementation and metadata framework.

Chair:

• Christian Nyffenegger (remote)
  In-room support:
• Gabriela Tazima (onsite, handling room device + Zoom)

Materials:

• Slides (PDF): Breakout sessions slides
• GitHub Repo: https://github.com/Link-Genetic-GmbH/lid/
• Discussion Issue: https://webirc.w3.org/?channels=linkid

Goals:

• Introduce LinkID as a general-purpose persistent identifier for hyperlinks.
• Present architecture, components, privacy & interoperability model.
• Validate the need for a W3C Community Group.
• Collect feedback from browser vendors, archives, PID ecosystem and W3C participants.

Digital payment authentication is nearly ubiquitous in all regions, yet payment security continues to collide with customer friction. With advancements in webAuthn extensions, digital credentials, and biometric authenticators, it’s clear that antiquated authentication methods like OTP are part of a fading past.

In this session, I’ll walk through Capital One’s digital payment authentication approach. Topics will include our thoughts towards Passkeys, challenges with our novel AirKey authentication method, and our journey to disintegrate a reliance on OTP.

This breakout will be divided into two parts:

• Part 1: External Metadata Integration — How ReSpec and Bikeshed could leverage shared metadata files (e.g. JSON files) to provide more details on the future of the specification. We'll discuss practical approaches to linking external data sources and improving maintainability. The use case mainly comes from the revamp of the CG program but there may be other needs.
• Part 2: Bikeshed support in spec-generator — We are looking at adding bikeshed support to spec-generator. We will present a demo and discuss what we are missing to replace the service from csswg.org.

@tabatkins, @marcoscaceres, @sidvishnoi, @kfranqueiro, @dontcallmedom, @tidoust, @vivienlacourba 👋

slides

Agentic AI aims to function with minimal user interaction.

APA's Discoverable Destinations
enables predictable programmatic access to common
web content components (such as login, contact data, store hours,
and more). Currently, such content is discovered by
brittle web scraping techniques that are unreliable and cumbersome to code.

Together they can super-charge classic piping and I/O redirection.

This breakout examines why people participate in W3C based on new research, Investigating Motivational Drivers of Participation in W3C’s Web Standards Development Process. I’ll share findings from a literature review and 13 semi‑structured interviews about W3C. Economic, philosophical, and moral drivers are revealed through the frameworks of game theory, design persons, and early Web philosophy. Also examined are the influence of structural dynamics like consensus requirements, proof‑of‑implementation norms, and the role of power players. After a concise briefing on the research's findings, I’ll open the floor for participants to share perspectives, challenge assumptions, and explore ideas for how these dynamics can or should shape the future of W3C standards work.