# 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.