W3C Breakouts Day 2024 calendar - Breakout Sessions

People already share their real identity on the Web, but they primarily share them through unsophisticated means: selfies, photographs of documents, and typing out numbers from identity documents. Countries are increasingly issuing their residents' identity documents in digital, cryptographic formats. Some jurisdictions, like the EU, will require that digital credentials be respected in multiple contexts, including on the Web.

We are at a critical point for the use of these identities on the Web; they are, for now, not part of the web platform and are not being presented online by most users. How long this lasts does not depend entirely on browsers. OpenID4VP describes multiple mechanisms to allow a website to request another application on the device that holds credentials to ask the user to prove their identity.

Work on building an API for presenting digital identity documents and designing how that must interact with wallets and existing identity protocols has begun in WICG. While the discussion there does extend beyond the purely technical, we think there is benefit in bringing a discussion to a broader audience with emphasis on the ecosystem, security, and privacy impacts of that work.

The following are just some of the questions that don’t have clear consensus:

• What should a browser store about wallets, credentials, and their use?
• To what extent should we trust the issuing government? Does that include trust for privacy properties?
• What are the use cases we should support? What justifies different approaches? What common aspects are shared?
• How does the role of the wallet as a user agent interact with that of the browser?
• What criteria must be required of real-world identity protocols to be included in the web platform?
• What conditions should be placed on release of data? Is consent the right control to apply here? Or should a credential issuer have a say as well?
• How do we ensure that use of credentials is justified and proportionate? Is there a need to establish a means to limit who can obtain credentials?

Goal(s):
Work toward a consensus view of what the role of Real World Identity should be on the Web in the next 5-10 years.

Track(s):

• identity

The move to Github for tracking our work - including actions, and various horizontal review tasks - has been a boon for productivity, and transparency. However, it can be hard to keep up to date with all the work that's going on, especially for TF facilitators, WG chairs, people who take part in horizontal review activities, and people who find the command line more accessible.

With a hat tipped to Tracker, our long-time action management tool, APA WG has been exploring the possibilities for presenting the rich and robust GitHub process on the command line. But this isn't just for APA WG; it's intended to be of use to TF facilitators and WG chairs across W3C.

Goal(s):
Demonstrate our command-line work tracking tool, and seek feedback from potential users

This session will have a short presentation about the current state of the work the RDF-Star WG is undertaking, followed by Q&A and discussion.

Goal(s):
Inform interested parties about RDF-Star (aka RDF 1.2)

The Web of Things Working Group is working on defining a registry mechanism where the wide WoT community, including other organizations like other SDOs, can contribute WoT bindings of existing protocols and media types. The WG has analyzed approaches within (official and not official ones) and outside of W3C and in this breakout we want to share our findings with the wide W3C, get inputs, and collaborate on building knowledge on how to manage registries for each technical report.

Goal(s):
Discussion and Collection of Opinion

Facilitating meetings in technical spaces is an important skill, and there are not many resources on how to do it for people new to the practice or new to W3C. Based on the meeting facilitation training developed by the Positive Work Environments CG at W3C, this session will provide a condensed version of the training covering how to effectively run meetings in a W3C context, how to handle code of conduct matters, and how to handle conflict.

Goal(s):
Provide meeting facilitators with information and guidance on running better meetings.

Navigation around sites can be complex, presenting barriers for people who struggle to understand the visual layout, or terminology that a site uses. However, there are several key sections or pages that can be found across many sites. The WAI-Adapt Task Force is exploring an approach (pending review) to address these barriers.

This session introduces the problem, shows how we envisage the solution working, from the user's perspective - via a demo of an interactive browser extension - and describes our proposed approach, in order to answer your questions, and gather informal feedback before we apply for horizontal and wide review from the community.

Goal(s):
Raise awareness of the challenges of site navigation, and a potential simple, semantic, standardized solution

Recently, we have come to the conclusion that FedCM should use CORS for the identity assertion endpoint. Other requests remain in question, like for example, the accounts endpoint have unique:

• Security constraints: like the response not being consumable by any script unless the user selects some browser UI
• Privacy requirements: like not being able to expose the RP to the IDP under any circumstance, which makes CORS an unsuitable primitive for this kind of request

Recently, Google has put together a proposal for finalizing the (security) properties of the account endpoints request, which involves interpreting the request as being "initiated" from the /.well-known file that directs the browser to fetch it (the accounts endpoint). Today, in practice that would make the accounts endpoint request "same-origin" with the /.well-known that initiated it, because FedCM requires that these requests be mutually same-origin.

We've reached some general agreement on this approach, but would like to discuss i with stakeholders including Fetch editors (@annevk), and also resolve outstanding discussion about how exactly cookies/credentials should be treated with this request.

Goal(s):
Resolve the topic of CORS & accounts endpoint requests

Track(s):

• identity

The Technical Architecture Group Privacy task force, together with participation from Privacy Interest Group, has been working on a set of privacy principles for the web. This is intended to be used by browser developers, authors of web specifications, reviewers of web specifications (such as the TAG and other groups participating in horizontal review), and web developers themselves. Now this document is going through wide review in advance of publication as a W3C Statement. We will present the principles and then have an open discussion.

Goal(s):
Increase awareness of the Privacy Principles, answer questions, gather feedback on how to improve the draft.

As a follow-up of Schemata Breakout of TPAC23, we want to further discuss ways to manage ontologies, schemas, and similar documents together. In the scope of the Thing Description Task Force at the Web of Things WG, we have analyzed some approaches such as LinkML, TreeLDR, Eclipse Semantic Modelling Framework, that we want to present. We have also identified that the topic of versioning, packaging, and serving these resources is a pressing topic that is not specific to the WoT. After these, we want to discuss on how to better continue the discussions in this topic area within the W3C.

Goal(s):
Discussion and Collection of Opinion

How do web developers talk about web features? What names do they use? How do these features map to specifications, fine-grained API functions and tests? What does a developer view tell us about the interoperability of the web platform?

The web-features project, envisioned in 2022 and launched in 2023, explores the set of interoperable features of the web platform by:

• Creating feature definitions, which identify and describe capabilities of web browsers.
• Generating Baseline support data, which summarizes the availability of web features across key browsers and releases.
• Publishing the web-features npm package, which bundles feature identifiers with Baseline statuses.

Developed by the WebDX Community Group and contributors, web-features data leverages compatibility data from the browser-compat-data project, is already integrated in MDN, Can I Use, Web Platform Tests, and is starting to reach additional authors of JavaScript libraries and dashboards.

Looking forward, feature identifiers at the "right" level make it possible to tag signals from the web community in surveys, browser standard positions, bug trackers, polyfills and usage counters. It also makes it easier to combine these signals with other projects that generate data out of specifications such as browser-specs and webref.

Features are also used in standardization groups, informally to organize discussions, but also formally to address transition requirements set forth by the W3C Process Document for advancing specifications on the Recommendation track. Within the Process, new features are defined as substantive changes that add new functionality, and used to assess implementation experience, document functionality that is considered at risk, and scope changes that may be incorporated in a specification depending on its maturity stage. This raises questions on the intersection between web-features and W3C’s standardization process, including:

• Can web-features provide useful information to working groups?
• Can it also inform the standardization process, e.g., to detect the need to transition a feature implemented by more than one browser out of incubation?
• What additional data or tooling would make web-features a powerful tool for standards bodies?
• How would you like to see web-features data presented in standards work?

Goal(s):
Share updates on the web-features project, its use to inform the standardization process, and additional data, tooling and visualizations to make web-features a powerful tool for standards bodies.

The proliferation of Generative AI has disrupted many industries and is poised to change significant aspects of our society. Without guardrails, we have often seen conversational AI agents overfitting to the bias in the training data which negatively impacts users. At eyeo, we build machine learning solutions on a web-scale, and in order to ensure our models are fair and sustainable, we have taken several concrete steps to transform the input data and calibrate the model evaluation to reflect real-world scenarios. We believe it’s high time to start a discussion around having a formal framework which outlines the ethical considerations for the use of Generative AI and AI in general. During the session, we will explore the challenges and opportunities that lie ahead from a technical and social perspective.

This builds on our session on Ethical AI during TPAC 2023, with a focus on Generative AI.

Goal(s):
Brainstorm ideas on the ethics of these new and upcoming technologies (Generative AI) and discuss the implications of adopting these on a large scale from a social, economic and technical perspective.

We would like to brainstorm ideas to solve the following problem: the FedCM API allows users to login to websites via some identity provider (IDP). Currently the API only allows the developer to specify a single IDP, and we are working on allowing multiple to be specified. It will be fairly easy to allow multiple IDPs in a single JavaScript call, but this has an issue. When there are multiple totally independent providers, we want each IDP to specify their desire to be included in FedCM independently. This allows the website to embed independent IDP SDKs into their site but still allow these IDPs to be shown in an aggregated browser dialog. The challenge is how to achieve this in a reasonable way. There are some brainstormed solutions here but we'd love to further discuss this in a session.

Goal(s):
Brainstorm ideas to tackle the problem of allowing multiple independent IDPs

Track(s):

• identity

The Web has billions of users, and most users have many, many dependencies on the web. The ecosystem around the web, which includes things like web engines, is both incredibly complex and fundamentally critical.

But the model that has driven, funded, and sustained this ecosystem isn’t ideal. There is no guarantee that it will be sustainable over the long term, but beyond that, it already falls quite short of funding everything that needs to be done. There is just too much. Many things go long ignored simply because prioritization is hard, and funds are ultimately limited. This includes everything from new features in popular languages like CSS and JS up to entire languages like MathML and SVG, which have largely been the work of (often unpaid) individual contributors.

In this session, we intend to have a community discussion of alternative models for funding the web ecosystem, from collective funding pools to changes in open source project policies to changes in tax law, and beyond.

Goal(s):
To help further discussions toward better solutions

The following proposal is based on this email and related discussion in the Gamepad API repo. Posted here as Chair of the WebApps WG.

This proposal for a W3C breakout session aims to address a critical limitation of the web as a platform for applications requiring low-latency response to user inputs. Despite technological advancements, the web's current input handling mechanisms are inadequate for such applications due to their dependence on the main thread.

User input APIs, which include keyboard, pointer, gamepad, HID, USB, MIDI, Bluetooth, and serial interfaces, are currently designed to register handlers on the main thread. This design results in inconsistent and unreliable response times, as the main thread is frequently occupied with other processes. This limitation adversely affects a broad range of applications, particularly those requiring precise user inputs, such as certain video games, Digital Audio Workstations (DAWs), synthesizers, and art programs that rely on touch gestures.

While incorporating timestamps in input APIs could offer some improvement, a more effective solution is to allow these APIs to be accessible from Web Workers. This change would significantly reduce input latency issues. Some APIs are already making progress in this direction, but others, especially those tied to the DOM API like keyboard and pointer events, face more complex challenges due to their inherent link to the main thread.

This issue, recently discussed with folks involved with the Gamepad API, highlights the need for a comprehensive approach that encompasses various APIs. Therefore, this session proposal seeks to gather community input and collaboration to explore and develop solutions that enhance the web's ability to handle user inputs with the necessary low latency. This effort requires a broad perspective and collective action, addressing the current limitations and identifying feasible paths for improvement in web application responsiveness.

Goal(s):
See if it's feasible to route some HID events to workers

The mission of the Real Estate Community Group is to provide a forum for real estate-related technical discussions to track progress of technology features on the Web within W3C groups, educate on the use of Web technologies by external organizations, and to identify use cases and requirements that existing and/or new specifications need to meet to deliver a more inclusive, robust experiences to the Real Estate ecosystem. This session will discuss the group, answer questions and briefly demonstrate the DO AudioTours technology built by Direct Offer.

Additional session chair: Amy Chorew.

Goal(s):
Get support for the group

The process of incubation, and some of its parameters, are not currently well-defined at W3C. I'd like to gather perspectives to further the work on Incubation in the AB (https://github.com/w3c/AB-memberonly/blob/master/documents/Incubation.md).

Some provoking questions to explore:

• How should incubation work?
• At what stage of "doneness" should work move from an incubation venue to a working group?
• How should an incubation group be communicating their work to a broader venue to ease acceptance as a WG deliverable?
• What expectation of incubation should there be before work is accepted into a WG, or into its charter?
• What best practices should we define for referring to incubations?

Goal(s):
Gather input and perspectives to further the AB work on improving incubation process

This breakout session is to talk about ideas we have regarding enabling installation of web apps and web content through the platform natively. This is a new proposal that aims at democratizing application distribution.

The goals for the session are to describe and generate discussion about the challenges functionality like this might have. The session is open to the public.

Goal(s):
Describe and generate discussion about the challenges functionality like this might have.

This session will serve to answer questions about the proposed Federated Identity Working Group, encouraging participation from all interested parties.

Goal(s):
Raise awareness of and encourage participation in the FedID WG

Track(s):

• identity

At the Secure the Web Forward workshop in 2023, writers from Open Web Docs led a discussion about the state of web security docs on MDN. One outcome from this was that OWD would draft an outline for some improved security documentation for MDN, which would be written in 2024.

We've now written up a draft outline and it's had some internal review: https://docs.google.com/document/d/1p1GtjmTd1uQrO2PRb_uUflAfQpEsfs7hBaopYeuoPMM/edit, and we're ready for some more extensive review of the outline before we start writing docs.

We're very keen on finding security experts to collaborate with us on this project, both in these early stages as we scope the project, and for detailed technical review of documents as we write them.

In this session, we'll present the draft outline, discuss any feedback, and next steps, which we hope will be making a start on the documentation!

Goal(s):
Review MDN web security docs outline proposal