[@@ from charter]
The Linked Web Storage Protocol specification aims to provide applications with secure and permissioned access to externally stored data in an interoperable way.
The Linked Web Storage Protocol does/does not include protocol details for integration with identity layers and mechanisms; access management and data integrity; notifications about resource changes; and authorization mechanisms.
This is an unofficial proposal.
List of TODOs and ideas in flux to enable editors to communicate asynchronously.
The LWS Protocol defines standard interactions by which a some party can make some resources available to some agents.
A resource manager may keep a served resource private, may make it publicly available to anyone, or may limited its visibility to a constrained set of requesting agents.
A LWS REST Server is an HTTP server [[!rfc9112]] that complies with all of the relevant "MUST" statements in this specification. Specifically, the relevant normative "MUST" statements in Sections 999 REST Binding of this document MUST be respected.
A LWS REST Client is an HTTP client [[!rfc9112]] that complies with all of the relevant "MUST" statements in this specification. Specifically, the relevant normative "MUST" statements in Sections 999 REST Binding of this document MUST be respected.
This specification defines operations on served resources, the resulting change of state, and a response indended to give the requesting agent requested infomation or inform them of the outcome of the operation. An operation is any of the following actions that can be performed on a served resource:
The folowing section will describe the semantics and responses of these operations but the following core responses apply to any operation:
For any access control that requires establishing the identity of a requesting agent, that identiy is established using strawman-authn:
{ "@context": ["https://strawman-authn"], "client_id": "https://app.example/id", "client_name": "Solid Application Name", "redirect_uris": ["https://app.example/callback"], "post_logout_redirect_uris": ["https://app.example/logout"], "client_uri": "https://app.example/", "logo_uri" : "https://app.example/logo.png", "tos_uri" : "https://app.example/tos.html", "scope" : "openid profile offline_access webid", "grant_types" : ["refresh_token","authorization_code"], "response_types" : ["code"], "default_max_age" : 3600, "require_auth_time" : true }
Define how requesting agents discover served resources and their capabilities.
In addition to the core responses, a create operation may produce any of:
The read resource operation requests a resource representation. Draw from Solid Protocol - Reading Resources.
The update resource modifies the contents of a served resource. Draw from Solid Protocol - Reading Resources.
Define the data model for logical resource organization within LWS, including how containers are structured, hierarchical relationships between resources, container semantics, containment rules, and the mechanisms for organizing and navigating collections of related resources. This should cover container creation, membership management, and the relationship between containers and the resources they contain.
This strawman mapping of the operations and responses defined above allows LWS REST Servers and LWS REST Clients to communicate over HTTP using REST conventions.
The following table maps LWS response to an HTTP status code and payload:
LWS response | HTTP status code | HTTP payload |
---|---|---|
success | 200 | resource representation |
not permitted | ... | |
unknown requester | ... | |
unknown error | ... | |
created | 201 |
Define how resources are identified and addressed within the LWS Protocol, including URI schemes, resource naming conventions, and resolution mechanisms. This section may be moved within another section; e.g. Resource Access
The features described in this section are being drafted to ground discussions and may be removed if there is:
Define mechanisms for content negotiation based on profiles, allowing clients to request specific representations or views of resources (e.g., JSON-LD contexts, different RDF serializations, or application-specific profiles).
Define notification mechanisms that allow clients to be informed of changes to resources, including subscription models, event formats, and delivery mechanisms.
Define inbox resources with specific semantics within LWS, including message posting, retrieval, and management capabilities for asynchronous communication patterns.
Describe considerations for ensuring LWS implementations can work across different platforms, environments, and storage backends while maintaining interoperability - and provide affordances to enable change in storage providers
Formal security considerations section covering threat models, security requirements, and implementation guidance for secure LWS deployments.
Privacy implications of the LWS Protocol, including data minimization, user consent, and privacy-preserving implementation patterns.