As per https://github.com/w3c-cg/solid/blob/main/CONTRIBUTING.md#new-work-item-proposal
and following the action of initial presentation/discussion in 2026-07-15 Solid CG meeting (minutes under review).
Application Capability: https://dokieli.github.io/application-capability/
Editors/Authors: Sarven (@csarven) and Virginia (@VirginiaBalseiro)
- Explain what you are trying to do, using no jargon or acronyms.
We want to communicate the capabilities and requirements of an application so that it can be used by other applications or servers to make more informed decisions.
- How is it done today, and what are the limits of the current practice?
To the best of our knowledge, information with regards to an application's capabilities and requirements is scattered across mechanisms that each cover a slice, such as web app manifests, browser permissions, and security policies. None of them lets a server or another application (e.g., an Web OS, launcher, catalogue, resource manager, etc.) discover what an application supports or needs. The result is hardcoded application lists, manual catalogue updates, and overly permissive policies.
- What is new in your approach, and why do you think it will be successful?
An application publishes one discoverable, structured description of its actions, supported resource types, how it can be invoked, and what permissions it needs, e.g., from a web user agent or server. It reuses existing vocabularies and notification mechanisms as much as possible.
There is a need in the community, with implementers already tackling parts of the problem outlined in Application Capability, and there is some implementation experience. This spec tries to bring prior discussions and work together (see CG minutes for background references) into something coherent that we can use.
- How are you involving participants from multiple skill sets and global locations in this work item? (Skill sets: technical, design, product, marketing, anthropological, and UX. Global locations: Africa, the Americas, APAC, Europe, Middle East, Antarctica.)
The authors/editors are based in Europe and have some familiarity with the web =) For more details, see their WebID, CV, etc.
- What actions are you taking to make this work item accessible to a non-technical audience?
We have tried to explain the problem space and related work as clearly as possible. Some of the use cases in the specification are written from the point of view of a user (with different abilities or roles).
We are available to answer questions, revise, and join meetings that have better open lines or access to a non-technical audience.
We also want to note that this work is not strictly limited to the Solid community. We have considered sharing it more widely with other groups and initiatives in W3C, e.g., Web Application(s) (Security) WGs, WICG, and elsewhere (see "related efforts" in the spec) that may be equally or more appropriate.
We want to make sure this is compatible with Solid and related efforts, and to incubate and gather experience here, while remaining open to migrating the work to another venue as we better understand where it can best mature and be useful in different context.
As per https://github.com/w3c-cg/solid/blob/main/CONTRIBUTING.md#new-work-item-proposal
and following the action of initial presentation/discussion in 2026-07-15 Solid CG meeting (minutes under review).
Application Capability: https://dokieli.github.io/application-capability/
Editors/Authors: Sarven (@csarven) and Virginia (@VirginiaBalseiro)
We want to communicate the capabilities and requirements of an application so that it can be used by other applications or servers to make more informed decisions.
To the best of our knowledge, information with regards to an application's capabilities and requirements is scattered across mechanisms that each cover a slice, such as web app manifests, browser permissions, and security policies. None of them lets a server or another application (e.g., an Web OS, launcher, catalogue, resource manager, etc.) discover what an application supports or needs. The result is hardcoded application lists, manual catalogue updates, and overly permissive policies.
An application publishes one discoverable, structured description of its actions, supported resource types, how it can be invoked, and what permissions it needs, e.g., from a web user agent or server. It reuses existing vocabularies and notification mechanisms as much as possible.
There is a need in the community, with implementers already tackling parts of the problem outlined in Application Capability, and there is some implementation experience. This spec tries to bring prior discussions and work together (see CG minutes for background references) into something coherent that we can use.
The authors/editors are based in Europe and have some familiarity with the web =) For more details, see their WebID, CV, etc.
We have tried to explain the problem space and related work as clearly as possible. Some of the use cases in the specification are written from the point of view of a user (with different abilities or roles).
We are available to answer questions, revise, and join meetings that have better open lines or access to a non-technical audience.
We also want to note that this work is not strictly limited to the Solid community. We have considered sharing it more widely with other groups and initiatives in W3C, e.g., Web Application(s) (Security) WGs, WICG, and elsewhere (see "related efforts" in the spec) that may be equally or more appropriate.
We want to make sure this is compatible with Solid and related efforts, and to incubate and gather experience here, while remaining open to migrating the work to another venue as we better understand where it can best mature and be useful in different context.