The Linked Web Storage (LWS) Protocol defines the minimum set of interoperable, HTTP-based interactions that let any conforming application read, write, and manage data that lives outside the application’s own infrastructure. Its purpose is to restore an essential architectural principle of the Web: users control where their data is stored while applications come and go—without breaking links, permissions, or provenance.
Today most Web applications entangle storage, identity, access control, and business logic behind a single origin. Migrating to a new provider or adopting a new application therefore often means abandoning existing data. LWS breaks that coupling. By standardising a small, resource-oriented contract it enables
- portable personal and enterprise data vaults that can move between providers, clouds, or on-premise deployments,
- application innovation decoupled from storage choices,
- consistent security semantics across heterogeneous back-ends, and
- a genuinely linkable data space, because every resource continues to be identified by an ordinary URI.
- Leverage, don’t reinvent. LWS reuses established Web building blocks—URI addressing, HTTP transfer semantics, RDF vocabularies—rather than introducing a parallel stack. Experience gained with Solid Protocol, WebDAV, ActivityPub, and modern object-storage APIs informed the design, but the specification remains deliberately minimal and composable, not monolithic.
- Layered extensibility. Capabilities such as real-time notifications, delegated authorization, or content-profile negotiation are specified as optional layers (see § 11 Unstable Features). The core stays small and future-proof.
- Security & privacy by default. The protocol assumes untrusted networks; authentication and authorization are required for any non-public resource, and all normative requirements are transport-agnostic but compatible with TLS-based deployments.
- Interoperability over optimisation. Where trade-offs arise, the Working Group prioritises a uniform client/server contract over provider-specific performance hints.
| Goals | Non-goals |
|---|---|
| Interoperability across vendors and platforms | Mandating a single identity system or token format |
| User-centred data portability | Defining a storage engine, database schema, or query language |
| End-to-end security and privacy controls | Specifying user-interface behaviour |
| Extensible feature set for advanced use cases | Baking experimental features into the core |
The specification defines two conformance classes:
- LWS REST Server – an HTTP origin that satisfies every normative requirement labelled “server”.
- LWS REST Client – an HTTP client that satisfies every normative requirement labelled “client”.
Unless a requirement states otherwise, it applies to both classes.
| Section | Content |
|---|---|
| § 3 | Terminology |
| § 4–6 | Discovery, authentication, and authorization flows |
| § 7 | Canonical create/read/update/delete operations and generic responses |
| § 8–10 | Logical organisation, REST binding, and resource identification rules |
| § 11 | Features under incubation (profile negotiation, notifications, inbox) |
| § 12–14 | Portability, security, and privacy considerations |
Readers implementing a client may start with § 7, referring back to § 4–6 for security prerequisites. Storage providers should pay particular attention to the conformance clauses in § 2.3 and the normative statements scattered through § 4–10.
GET /photos/2025/06/puppy.jpg HTTP/1.1
Host: storage.example
Accept: image/jpeg
HTTP/1.1 200 OK
Content-Type: image/jpeg
Last-Modified: Fri, 06 Jun 2025 13:37:42 GMT
The pattern is identical for create, update, and delete operations, which are detailed in § 7.