---
# System prepended metadata

title: Prioritized Roadmap (for Review)

---

# Prioritized Roadmap (for Review)

The following is a list of Solid Roadmap Milestones, force-ranked in priority order (*note: still pending review)*.

## Secure Websockets / Solid Notifications Protocol

Consider proposals to add normative language to the [Solid Protocol Specification](https://solidproject.org/TR/protocol) that requires support for the [WebSocketSubscription2021](https://solid.github.io/notifications/protocol#websocketsubscription2021) subscription type as specified by the [Solid Notifications Protocol](https://solid.github.io/notifications/protocol). Ensure that the language does not restrict support for additional subscription types (e.g. EventSourceSubscription2021, WebHookSubscription2021, LinkedDataNotificationSubscription2021, etc.), which may or may not be added as normative requirements to the protocol specification at a later date.

## Server Capability Discovery

Consider proposals to add normative language to the [Solid Protocol Specification](https://solidproject.org/TR/protocol) that details how a client may determine capabilities and/or features offered by a given Solid server. For example, if a server supports additional notification types beyond WebSocketSubscription2021, or server-side validation by a given mechanism.

## Authorization by Client Identifier

Consider proposals to add normative language to the [Solid Protocol Specification](https://solidproject.org/TR/protocol) that requires any supported access control system (e.g. WAC, ACP) to enable or restrict access by a client application identifier.

## ACP

Consider proposal to add normative language to the [Solid Protocol Specification](https://solidproject.org/TR/protocol) that adds [Access Control Policies](https://solid.github.io/authorization-panel/acp-specification/index.html) as a supported access control system.

## Access Modes

Consider proposals to add more granular access modes to Solid access control system specifications (i.e. WAC, ACP) and to the ACL vocabulary. These modes must maintain backwards compatibility with existing modes and rules, while allowing for more precise definition of authorization rules moving forward. Specifically, provide acl:Create, acl:Delete, acl:Update as alternatives to what is currently provided by one mode; acl:Write.

## Data Validation

Consider adding normative language to the [Solid Protocol Specification](https://solidproject.org/TR/protocol) to support server-side data validation through standards-based mechanisms, such as Data Shapes ([ShEx](http://shex.io/shex-semantics/), [SHACL](https://www.w3.org/TR/shacl/)) and [Shape Trees](https://shapetrees.org/TR/specification/).

## Evaluate and establish strategy to incorporate Verifiable Credentials

Establish a strategy for where and how verifiable credentials can be leveraged in the Solid ecosystem, including but not limited to:

- As a means for authorization (as opposed to social agent identity)
- Issuing verifiable credentials
- Verifiable credentials verification
- Verifiable credential storage and retrieval (if not directly on pod through regular mechanisms)
- As a companion auxiliary resource type (e.g. for checking data integrity of an associated resource)
- As a means through which applications and/or agents in the ecosystem can be "certified" as another third party

The outcome of this effort may include the addition and subsequent prioritization of additional roadmap milestones.

## Access Request and Access Grant Patterns

Review proposals including but not limited the [Solid Application Interoperability Specification](https://solid.github.io/data-interoperability-panel/specification/) that specify how access to a given resource can be requested and granted.

## Additional Notification Types

Consider proposals to add normative language to the [Solid Protocol Specification](https://solidproject.org/TR/protocol) that add support for additional Notification Types detailed by the [Solid Notifications Protocol](https://solid.github.io/notifications/protocol), including but not limited to [EventSourceSubscription2021](https://solid.github.io/notifications/protocol#eventsourcesubscription2021), [LinkedDataNotificationSubscription2021](https://solid.github.io/notifications/protocol#linkeddatanotificationssubscription2021), and [WebHookSubscription2021](https://solid.github.io/notifications/protocol#webhooksubscription2021).

## Dynamic Auxiliary Resource Extensions

Consider normative language to the [Solid Protocol Specification] that allows new auxiliary resource types to be dynamically created and assigned within the protocol.

## Virtual Hosting

Ability to let people bring their own domains. May need to standardize how to validate the user is the owner of a given domain.

## Standardize Interface for Pod Provisioning



# Necessary Dependencies

## Engagement infrastructure

Set up dashboards, project management tools etc, to ensure that interested parties are able to engage in spec development process

## Conformance Test Coverage

Consider setting a goal for [conformance test](https://github.com/solid/specification-tests/) coverage. It is likely that writing tests will surface that some formulations in the specification are untestable, so this will bring specification text in line with the logic in tests.