Copyright © 2025 World Wide Web Consortium . W3C ® liability , trademark and permissive document license rules apply.
[@@ 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 section describes the status of this document at the time of its publication. A list of current W3C publications and the latest revision of this technical report can be found in the W3C standards and drafts index at https://www.w3.org/TR/.
This is an unofficial proposal.
This document was published by the Linked Web Storage Working Group as an Editor's Draft.
Publication as an Editor's Draft does not imply endorsement by W3C and its Members.
This is a draft document and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.
This document was produced by a group operating under the W3C Patent Policy . W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy .
This document is governed by the 03 November 2023 W3C Process Document .
This section is non-normative.
List of TODO s and ideas in flux to enable editors to communicate asynchronously.
This section is non-normative.
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 .
As well as sections marked as non-normative, all authoring guidelines, diagrams, examples, and notes in this specification are non-normative. Everything else in this specification is normative.
The key words MUST and MUST NOT in this document are to be interpreted as described in BCP 14 [ RFC2119 ] [ RFC8174 ] when, and only when, they appear in all capitals, as shown here.
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.
Referenced in:
Referenced in: