Linked Web Storage Use Cases

W3C Group Draft Note

More details about this document
This version:
https://www.w3.org/TR/2025/DNOTE-lws-ucs-20250624/
Latest published version:
https://www.w3.org/TR/lws-ucs/
Latest editor's draft:
https://w3c.github.io/lws-ucs/
History:
https://www.w3.org/standards/history/lws-ucs/
Commit history
Editor:
Hadrian Zbarcea
Feedback:
GitHub w3c/lws-ucs (pull requests, new issue, open issues)

Abstract

User stories and use cases for the Linked Web Storage (LWS) spec.

Status of This Document

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.

1. Introduction

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.

2. Use Cases

The use cases for the LWS specifications are documented below.

2.1 Functional Stories

2.1.1 Generic Storage

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.

2.1.2 Portable Storage

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.

2.1.3 Sharing Access

As an author with authoring permission, Guinan uses the sharing interface of her authoring tool to manage access to her article, so that Deanna can review, Seven-of-Nine can co-edit, and Torres can view the progress. All user(s) — Guinan, Deanna, Seven-of-Nine, and Torres — have personal online identities that can be used to assign these permissions.

The sharing interface of the protocol shall ensure that each user receives the appropriate access without confusion. The protocol shall handle updates to access permissions, and determine whether changes should trigger notifications to the target user(s).

2.1.4 Profile Sharing

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.

2.1.5 Group Sharing

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.

2.1.6 Administrative Assistant

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.

2.1.7 Offline Data

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.

2.1.8 Large HTTP uploads

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

2.1.8.1 References:

2.2 Non-Functional Stories

2.3 Technical Stories

2.4 Spike Stories

3. Requirements

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
  1. Globally Unique Identifiers — Resources, including Entities and Storages, shall be uniquely identifiable globally. No two distinct Resources shall share the same Identifier (though a "collective" Resource with one Identifier may be comprised of several Resources, each with its own Identifier, and actions taken on the collective Resource can affect all the Resources which comprise the collective Resource). A Resource may be identifiable via multiple, distinct identifiers. A Resource Owner shall be able to prove control of owned Resource Identifiers.
  2. Use of Service Providers — The protocol shall provide a mechanism for Entities to delegate some functions to trusted Service Providers. Some interactions may require a trust relationship between Service Providers and Entities. In general, this should not impede the ability of an Entity to operate or self-host a service. Also, trust relationship are not transitive, in the sense that if an Entity trusts a Service Provider, e.g. an Identity Provider, it does not follow that another Service Provider the Entity interacts with, e.g. a Storage Provider, is under any obligation to trust said Identity Provider.
  3. Control of Storages — An Entity shall be able to control one or more Storages across one or more Storage Providers. A Storage shall have exactly one Controller.
  4. Delegation of Control — The system shall allow for an Entity to delegate control of a Storage to another Entity. Delegation could be temporary, i.e. have an expiration time, or not. An Entity shall be able to modify delegation at a later time, either by changing expiration of revoking it altogether.
  5. Transfer of Control — The protocol shall allow for an Entity to transfer, i.e. irrevocably reassign control of a Storage to another Entity.
  6. Storage Portability — The protocol shall allow for an Entity to port, i.e. move or transfer, the entire contents of a Storage from one Storage Provider to another. Once the move is complete, the previous Storage Provider shall be freed from any responsibility related to the Storage.
  7. Adding, Updating, Deleting Resources in Storage — The protocol shall allow for Resources to be added, updated and/or deleted within a Storage by authorized Entities. In general the protocol shall allow for any type of resource to be stored in a Storage, however Storage Providers may impose certain limitations, such as of type or size.
  8. Data Sharing — The protocol shall allow an Entity to grant give access to a Resource it controls to another Entity. In other words, the first Entity may allow the other Entity to perform some operations (read, modify, remove...) on the Resource. Access grant could be temporary, i.e. have an expiration time, or not. The first Entity shall be able to modify delegation at a later time, either by changing the expiration time of revoking it altogether.
  9. Auditable Trail — The protocol shall make it possible for an authorized Entity to access an auditable log of all access requests and grants to Resources and all read/write/delete of Resources.
  10. Serialization Format — The protocol shall make it possible for data in a Storage to be serialized in a known format.

4. Glossary

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.

A. References

A.1 Informative references

[RESUMABLE_UPLOADS]
Resumable Uploads for HTTP. M. Kleidl; G. Zhang; L. Pardue. IETF. 3 December 2024. Draft. URL: https://httpwg.org/http-extensions/draft-ietf-httpbis-resumable-upload