Skip to main content
Note: This is an unofficial information page about the W3C Linked Web Storage initiative. For official information, please visit the W3C Linked Web Storage Working Group Charter.
•W3C Initiative 2024-2026

Linked Web Storage: Taking Back Control of Your Data

Imagine a web where you decide where your data is stored and who can access it. That's the future the W3C Linked Web Storage Working Group is building.

Learn More → Join the Initiative
⊙
User-Controlled Storage
⊗
Decentralized Data
⊛
Enhanced Privacy
2024-26
Development Timeline

What is Linked Web Storage?

Linked Web Storage is a new approach to how data is handled on the web. It aims to give you more control over your personal information by allowing you to choose where your data is stored and who can access it.

The W3C is actively developing the LWS Protocol specification, which defines standard interactions for secure and permissioned access to externally stored data. This protocol includes authentication, authorization, and resource management capabilities that enable true user-controlled data storage on the web.

Historical Note: LWS builds on the Solid Project, which has been incubated by the W3C Solid Community Group since 2018. The Linked Web Storage Working Group was formed in 2024 to bring these specifications to official W3C Recommendation status.

Why Does This Matter?

Currently, when you use most web services, your data is stored and controlled by the service provider. This can limit your ability to switch between services or control who has access to your information. Linked Web Storage aims to change that, giving you more freedom and control.

What Will This Enable?

Current Progress & Timeline

Latest Update: November 2025

The W3C has published the Linked Web Storage Use Cases document as a Group Draft Note, defining 39 core requirements across data management, access control, collaboration, and security.

The LWS Protocol 1.0 specification now includes four authentication suites supporting OpenID Connect, SAML 2.0, and decentralized identifiers (did:key).

The W3C Linked Web Storage Working Group is working on this from September 2024 to September 2026. With the protocol specification now in active development, we're seeing concrete progress toward a more user-centric web. While it may take some time before these changes are widely adopted, this work is laying the foundation for true data ownership and control.

For Developers

Ready to build with Linked Web Storage? Here are the key technical resources to get started:

LWS Protocol 1.0 Core

Core specification for REST servers and clients

Use Cases & Requirements

39 requirements across data, access control, and security

Protocol Repository

Contribute to development, file issues, track progress

Join the Working Group

Participate in weekly meetings and spec development

Authentication Suites: The spec supports OpenID Connect, SAML 2.0, did:key, and controlled identifiers for flexible authentication options.

Conformance & Test Suites

LWS is testable. Two harnesses run against a live server and report in W3C EARL, so "implements LWS" is a number rather than a claim.

  • • Touchstone — the LWS conformance harness: 221 YAML-LD server tests covering the core protocol (moving resources included), the webhook notification suite, the type index and search services, and all three authentication suites, baselined on the 19 October 2026 drafts; client rules too. Runs as a CLI, a Docker image, a GitHub Action, or an MCP server; reports in EARL, HTML, JUnit, and PDF. By Erich Bremer.
  • • lws-test-suite — the LWS test group's own manifest, the one the W3C specification repository links to. Reset on 11 October 2026 to a 39-test Turtle baseline of core-protocol tests taken from LWS.net ("not a final consensus, just a current baseline"); the place where the official suite is being shaped.
  • • LWS.net — a .NET test suite and reference server by Samu Lang, the source of the current lws-test-suite baseline; runs against any server from a base URI, with traces in an Aspire dashboard.

Touchstone results

Erich Bremer runs Touchstone against every known server and republishes the results on each harness update at ebremer.com/lws/conformance — the current numbers live there. Snapshot of 19–21 October 2026 (221 tests, the 19 October 2026 drafts):

Server Language Passed Failed Not applicable Verdict
lws-drupal PHP210 / 221011 conformant
lwsd JavaScript209 / 221012 conformant (tracker, 21 Oct; 210 / 0 / 11 in lwsd's own run of the same harness)
lws-server Java207 / 221014 conformant
Halcyon Java204 / 221017 conformant
sparq-lws-core Rust192 / 2211613 not conformant (16 MUST)
Community Solid Server + lws plugin TypeScript118 / 2214063 not conformant (35 MUST)

"Not applicable" tests needed a capability the deployment did not declare (SAML trust, for instance) and are not passes. Results are taken from the tracker on the date shown; the harness and the drafts both move, so check the live page.

Implementations

A living list of software implementing or building on Linked Web Storage, grouped by role. LWS has a producer side (servers that serve pods) and a consumer side (clients and apps that read from and write to pods). Both are implementations.

Servers (produce LWS storage)

  • • lwsd — LWS Daemon, in JavaScript: the LWS 1.0 core protocol, the embedded authorization server (RFC 8693 token exchange, RFC 9728 discovery), access requests and grants (ODRL), signed webhook notifications (RFC 9421), the type index and search services (HTTP QUERY), moving resources between containers, the CID (did:key, Nostr keys and HTTPS) and OpenID Connect authentication suites, and a one-file todo app served at /todo/. 209 of 221 Touchstone tests pass on the tracker (0 failed) — conformant against the 19 October 2026 drafts. A plugin on JSS; one command: npx lwsd.
  • • @solid/community-server-lws — LWS for the Community Solid Server (CSS v8), as a Components.js plugin: LWS alone or side by side with the Solid Protocol on the same pods, with WAC or ACP authorization. By Jesse Wright.
  • • lws-server — an LWS server in Java (Jakarta servlets on embedded Jetty) with an embedded authorization server, all three authentication suites, WAC, SPARQL, DPoP, and ACME TLS. By Erich Bremer.
  • • JavaScript Solid Server (JSS) — the Solid server that hosts lwsd, and the one server that serves all three storage protocols the LWS charter names from a single pod: the Solid Protocol (WebID, Solid-OIDC, WAC, LDP), remoteStorage (draft-dejong-remotestorage-22, with WebFinger discovery and OAuth), and LWS through lwsd (Touchstone-conformant). Profiles are W3C Controlled Identifier documents; did:nostr and NIP-98 are accepted too. One-command install: npx jspod.
  • • lws-drupal — a Drupal module exposing a site as Linked Web Storage.

Clients & Apps (consume LWS storage)

  • • mashlib-lws — a data browser for LWS storage: an LWS-native shell (browse, edit with ETags, create, type search, ODRL sharing, inbox, did:key or OpenID login) that mounts every SolidOS pane as a plugin, with no build step. Hosted at linkedwebstorage.github.io/mashlib-lws, or served by the storage itself (lwsd --browser).
  • • lws-client — LWS client libraries in Java, Rust, C++, JavaScript, Python, Go, C#, WebAssembly, Swift, PHP, and Kotlin.
  • • lws-fuse — mount an LWS storage as a filesystem (FUSE).
  • • Porter — pure-Deno multi-agent orchestration platform. Stores agent teams, models, MCP servers, and credentials in LWS pods via SSO and server-side token exchange, so configuration persists across deployments.

Libraries & Authentication

  • • lws-authn — a Keycloak extension implementing all three LWS 1.0 authentication suites: OpenID Connect, Self-signed Identity (CID: HTTPS, did:key, did:web), and SAML 2.0.
  • • lws-keycloak — a Keycloak-based prototype of LWS authentication and authorization.
  • • carbon-cid — a Java implementation of W3C Controlled Identifiers (CID), the standard underpinning LWS authentication.
Adding an implementation: open a pull request against linkedwebstorage.com with your implementation, its role (server / client / library), and the LWS surface it implements.

Frequently Asked Questions

What's the difference between LWS and Solid? ▼
LWS (Linked Web Storage) is the W3C standardization effort that builds on the Solid Project. The Solid Community Group incubated the specifications since 2018, and the LWS Working Group was formed in 2024 to bring these to official W3C Recommendation status.
When will LWS be ready for production use? ▼
The specifications are W3C Working Drafts (core protocol: 19 October 2026) under a Working Group whose charter is being renewed. They are implementable today: a conformance harness exists, and servers pass it (see Conformance & Test Suites above). Expect details to move until Candidate Recommendation; check the protocol spec for current requirements.
How can I contribute to LWS development? ▼
You can contribute through the GitHub repositories, participate in Working Group meetings, or submit use cases to the Use Cases repository.
Is this an official W3C website? ▼
No, this is an unofficial informational resource. For official information, visit the W3C Linked Web Storage Working Group Charter or the official Working Group page.

Related Resources

Official W3C Documents

GitHub Repositories

Related Projects