Copyright © 2024-2025 World Wide Web Consortium. W3C® liability, trademark and permissive document license rules apply.
User stories and use cases for the Linked Web Storage (LWS) spec.
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 document was published by the Linked Web Storage Working Group as a Group Draft Note using the Note track.
Group Draft Notes are not endorsed by W3C nor 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.
The W3C Patent Policy does not carry any licensing requirements or commitments on this document.
This document is governed by the 03 November 2023 W3C Process Document.
The LWS specifications aim to enable the development of web applications where data storage, entity authentication, access control, and application provider are all loosely coupled, as compared to the web of today where these are typically all tightly coupled, so changing one requires changing all, sometimes at a cost of all past data.
This document lists user stories and use-cases for the LWS specifications, as well as requirements identified as necessary to satisfy these use cases.
The use cases for the LWS specifications are documented below.
Bob wants to store and organize his data in a storage
available online, so that data can be accessed from any device, any location, at any time. Bob wants to be free to store any type of resource in the storage
. Bob wants his storage
to allow for resources to be added, updated, and/or deleted.
Bob wants the ability and choice to host the storage
himself, or delegate the hosting to a storage provider
. A storage provider
may impose certain limitations, such as resource type or size, and Bob may accept that if informed in advance. Bob also wants the ability to move (a/k/a port) his storage
to another storage provider
as desired, without losing any access to existing data or metadata, so that Bob is not dependent in perpetuity on one storage provider
.
Porting a storage
from one provider to another should work the same even when Bob hosts the storage
himself. In that situation Bob also acts as storage provider
.
Alice wants to maintain and manage multiple profiles and have fine grained choice over who can see which profile(s), so that she can maintain her privacy. Alice wants to know and trust Bob's identity, the user
she shares her data with, so that Mallory, a malicious actor, cannot impersonate Bob and gain access to her data.
Charlie learns about Alice's profile and tries to access it from his business card management application called SolidRolodex. He's not able to see it, because he was not yet granted access. Charlie needs a way to request access to Alice's profile from his app. Once Alice receives and approves Charlie's request, he will be able to access and see the data.
Alice is organizing a conference and stores a calendar for the conference in a Storage. Alice wants to share the calendar with the whole group of participants to the conference. The group of participants changes all the time during the registration process, new participants register and some drop out. Alice does not want to have to update the sharing grants every time the group composition changes.
Some of the participants are also speakers at the conference. They will need elevated permissions, such the ability to update the description of their presentation or upload and attach slides.
Charlie is the keynote speaker at the conference organized by Alice. Erin is his administrative assistant. Charlie wants to delegate the access granted to him by Alice to Erin so that she can make updates on his behalf. Charlie wants to delgate some, but not all, of his permissions, to Erin.
Bob wants his storage to be available offline on his own device. He uses tools that access data in storages controlled either by himself or other trusted entities. Bob is sometimes disconnected from the internet, but would like to use his tools, so he needs local copies of his data or data shared with him. Bob would like data to be read-only at the very least, but, ideally, writable as well and synchronized once he regains internet connection. For the data available offline, Bob wants some strong guarantees that the data was not corrupted.
As a user
, I want to upload large files that may or may/not succeed in total due to network and/or server issues. Further, knowing what percentage of a large file was successfully transferred can be handy to have as both user and developer.
See also https://github.com/w3c/lws-ucs/issues/18
The following requirements were identified and sufficient to satisfy the use cases above. This is a non-normative document and the workgroup may decide that some requirements are out of scope.
1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | |
---|---|---|---|---|---|---|---|---|---|---|
Generic Storage | ✓ | ✓ | ✓ | |||||||
Portable Storage | ✓ | ✓ | ✓ | |||||||
Sharing Access | ✓ | ✓ | ✓ | ✓ | ||||||
Profile Sharing | ✓ | ✓ | ✓ | ✓ | ||||||
Group Sharing | ✓ | ✓ | ✓ | ✓ | ||||||
Administrative Assistant | ✓ | ✓ | ✓ | ✓ | ||||||
Offline Data | ✓ | ✓ | ✓ |
The glossary provides definitions of key terms and concepts used throughout this specification. It serves as a quick reference to ensure clarity and a shared understanding among readers and contributors. By standardizing terminology, the glossary supports consistent communication and alignment in interpreting this specification.