Application Capability - W3C TPAC 2026 All-Community meeting, Exploration IG SEED

More details about this document
Identifier
https://csarven.ca/presentations/application-capability-tpac-seed
Author
Sarven Capadisli
Published
Modified
License
CC BY 4.0
Language
English
Document Type
Slideshow
Inbox
https://csarven.ca/presentations/inbox/ac-seed/
Topics
Audience

Application Capability

W3C TPAC 2026, All-Community meeting, Exploration IG SEED, Dublin,

Sarven Capadisli's avatar Sarven Capadisli https://csarven.ca/#i @csarven

Background, Problem, Opportunity

What
Machine-readable description of an application. Capabilities, invocations, requirements, policies, communication.
Problem
People choose the applications for their resources.
No reliable way to discover what they can do, what they need, how to invoke.
Hard-coded today, or in platform stores. Same problem for AI agents.
Opportunity
One authoritative description at an IRI. Discover, match, invoke.
No central registries or prior coordination.

W3C Relevance

Fits the web architecture
Declarative. Invocation is navigation. No browser engine changes.
The web is the distribution platform. Applications reached by link, not store.
Builds on Web Application Manifest, CSP, Permissions, DPV, Hydra. Complements WebMCP.
Taken up at W3C
TAG early design review led to the Exploration IG. Also in the Threat Modeling CG.
Spec maturity
TAG explainer, clear Conformance, extensive Considerations.

Interoperability Pressure

Across parties
Applications, servers, user agents, catalogues, AI agents.
Web, PWA, desktop. One declaration for humans and agents. No divergence.
Evidence of demand
Parallel efforts on pieces of this. file_handlers, protocol handlers, WebMCP, MCP registries. Each scoped to a platform or loaded page.
Agent ecosystems are settling now. Fragmentation or closed registries by default.
Implementable; dokieli, independent validator, and others expressed interest; PodOS.

Thanks! Questions or Comments?

Which route at W3C is the right next step?