Linked Web Storage Use Cases

W3C Editor's Draft

More details about this document
This version:
https://w3c.github.io/lws-ucs/
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
Editors:
Pierre-Antoine Champin
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 is a preview

Do not attempt to implement this version of the specification. Do not reference this version as authoritative in any way. Instead, see https://w3c.github.io/lws-ucs/ for the Editor's draft.

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 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.

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 Data Management

  • Generic Storage
    As a user, I want a format-agnostic online storage system that supports any type of resource, so that I can perform Create, Read, Update, and Delete (CRUD) — including metadata and access-control modifications, as well as recovering previous versions—from any device at any time.
    Context: This ensures seamless data management across devices, empowering users with full control over their resources.
    Issues: #117, #97, #60, #63, #62, #69

  • Portable Storage
    As a user, I want the ability to self-host my storage or switch between providers without losing my data, so that I retain data sovereignty and can withstand provider outages or migrations without data loss.
    Context: Portability prevents vendor lock-in and enhances data sovereignty.
    Issues: #30, #58, #140, #61

  • Offline Data Access
    As a user, I want to access and modify my data offline, with automatic synchronization upon reconnection, so that I can work without a network and avoid data corruption or conflicts.
    Context: Offline support is vital for users in areas with unreliable connectivity.
    Issues: #138, #64, #65, #67

  • Large File Uploads
    As a user, I want to upload large files with resumable uploads, so that interruptions don’t force me to restart the entire transfer.
    Context: This improves usability for managing large media or data files.
    Issues: #18

2.1.2 Access Control and Sharing

  • Sharing Access
    As a data owner, I want to grant and revoke fine-grained permissions on my resources, so that collaborators have appropriate access and receive notifications when their permissions change.
    Context: Granular control ensures secure and tailored data sharing.
    Issues: #7, #27, #116, #148, #120, #98

  • Notifications for Permission Changes As a collaborator, I want to receive notifications when my permissions on a resource are granted, revoked, or modified, so that I am informed about changes to my access rights in a timely manner. Context: Timely notifications help collaborators stay updated on their access to shared resources, enhancing collaboration and security. Issues: #116, #78

  • Profile Sharing
    As a user, I want to maintain multiple profiles with distinct access controls, so that I can share specific information while keeping other data private.
    Context: Multiple profiles support different personas or contexts (e.g., work vs. personal).
    Issues: #29, #57

  • Group Sharing
    As a user, I want to share data with dynamic groups (e.g., event attendees), so that membership and permissions update automatically as the group evolves.
    Context: This simplifies access management for temporary or changing collaborations.
    Issues: #38, #102

  • Administrative Assistant
    As a user, I want to delegate specific permissions to an assistant, with audit logs tracking their actions, so that they can manage my data securely on my behalf.
    Context: Delegation aids users needing assistance while maintaining oversight.
    Issues: #10, #104, #118

  • Context-Aware Access Policies
    As an administrator, I want to enforce access policies based on contextual factors like time or geolocation or relative location (near Bob), so that access to data adapts dynamically to real-world conditions.
    Context: Context-aware policies enhance security and flexibility.
    Issues: #17, #147, #94

  • Health Record Access
    As a patient, I want to share specific health records with an AI assistant using delegated authorization, so that I can get a second opinion with audit logs ensuring accountability.
    Context: This supports secure, audited health data sharing for informed decisions.
    Issues: #11, #46, #54

2.1.3 Collaboration and Communication

  • Meeting Scheduling
    As a user, I want to schedule meetings directly through my storage, with conflict detection for online and offline scenarios, so that I avoid double-booking.
    Context: Integrated scheduling boosts productivity and coordination.
    Issues: #3, #42

  • Real-Time Notifications
    As a collaborator, I want real-time notifications when resources I access are updated, so that I stay informed without manual checks.
    Context: Timely updates enhance collaboration efficiency.
    Issues: #32, #79

  • Application Notifications
    As a user, I want email or web push notifications for storage activity, so that I remain aware of important events.
    Context: Notifications keep users engaged with their data.
    Issues: #100

  • Universal Communication
    As a user, I want direct messaging channels with other storage owners, so that I can collaborate seamlessly within the platform.
    Context: Built-in communication strengthens user interaction.
    Issues: #99, #22

  • Polling
    As a user, I want to create and manage polls within my storage, so that I can gather opinions and feedback from others.
    Context: Polls support decision-making and community engagement.
    Issues: #144

  • Semantic Collaboration
    As a user, I want to co-author structured content with others using permanent URIs and flexible permissions, so that collaboration is efficient and traceable.
    Context: This enables advanced use cases like shared knowledge bases.
    Issues: #146, #98

2.1.4 Application Integration

  • Personal Information Management
    As a user, I want to manage my personal data in my storage and integrate it with non-Solid apps via some data transformation, so that I can use various apps without creating data silos.
    Context: This promotes interoperability and user control.
    Issues: #2

  • Bring-Your-Own-Data Apps
    As an app developer, I want my applications to store data in user's storage, with support for CRUD operations and store discovery, so that users retain ownership and control of their data.
    Context: This shifts data ownership from apps to users.
    Issues: #12, #120

  • Digital Goods Delivery
    As a user, I want secure delivery of digital goods (e.g., software, media) with confirmation receipts, so that providers can deliver assets with minimal intervention.
    Context: This ensures reliable digital product delivery.
    Issues: #14

  • Data Integration
    As an app developer, I want a standardized API to combine data from multiple sources, so that integrating diverse datasets is straightforward and efficient.
    Context: Simplified integration reduces development complexity.
    Issues: #26, #53, #88, #106

  • Business Data Access
    As a business user, I want clear enforcement rules for data sharing, so that enterprise integrations comply with organizational policies.
    Context: This supports secure enterprise use cases.
    Issues: #27, #28

2.1.5 Advanced Features

  • Timeseries Storage
    As a user, I want to store timeseries data with resolution limits and multidimensional analysis support, so that I can efficiently analyze trends over time.
    Context: This is critical for applications like IoT or analytics.
    Issues: #6

  • Sensor Data Sharing
    As a user, I want to share sensor data at varying levels of granularity without duplication, so that consumers receive only the detail they need.
    Context: Efficient sharing reduces resource usage.
    Issues: #8

  • Legal Reporting
    As a data provider, I want verifiable proof of data sharing to support audit compliance, so that I can meet legal obligations even after access is revoked.
    Context: This ensures transparency and accountability.
    Issues: #9

  • Search Functionality
    As a user, I want powerful search capabilities with contextual awareness and security enforcement, so that I can find relevant resources quickly and safely.
    Context: Effective search is essential for large datasets.
    Issues: #152, #87

  • Pagination & Filtering
    As a user, I want efficient pagination, filtering, and ordering of search results, so that I can navigate large datasets easily.
    Context: These features enhance data usability.
    Issues: #103

  • SPARQL Queries
    As a power user, I want support for SPARQL queries to perform complex searches and data analysis, so that I can extract insights from linked data.
    Context: SPARQL enables advanced semantic web queries.
    Issues: #45

  • Website Creation
    As a user, I want to publish self-describing websites with persistent URIs, so that my content remains accessible and interoperable over time.
    Context: This supports durable web publishing.
    Issues: #31

  • Home Access
    As a user, I want to access my storage from home devices with dynamic IPs, so that connectivity issues don’t prevent me from using my data.
    Context: This ensures accessibility in home environments.
    Issues: #105, #68

  • Contextual Interactions
    As a user, I want context-aware display of interactions alongside content, so that I can understand permissions and history intuitively.
    Context: This improves user understanding of data interactions.
    Issues: #55

  • WebID Profile Interaction
    As a user, I want clicking a WebID to display profiles and available actions, so that I can engage with contacts effortlessly.
    Context: This enhances social and professional interactions.
    Issues: #48, #47

  • Storage Listening
    As an app developer, I want offline monitoring of storage changes, so that my applications stay synchronized even without connectivity.
    Context: This supports robust offline app functionality.
    Issues: #101


2.2 Non-Functional Stories

2.2.1 Security and Privacy

  • End-to-End Encryption
    As a user, I want end-to-end encryption for all data storage and transfers, so that only authorized parties can decrypt and access my information.
    Context: Encryption ensures data confidentiality.
    Issues: #4, #44, #73, #74, #75, #76

  • Consent-Based Sharing
    As a user, I want verifiable consent mechanisms with audit trails for data sharing, so that I can ensure compliance with privacy regulations.
    Context: Consent management supports ethical data practices.
    Issues: #141, #80, #81, #82, #83, #84, #85, #86

  • Legal Grounds Support
    As a compliance officer, I want to define access policies based on legal grounds (e.g., GDPR), so that data sharing adheres to regulatory requirements.
    Context: This ensures global compliance readiness.
    Issues: #80, #141, #77

2.2.2 Performance and Usability

  • Storage Ownership
    As a user, I want ownership assigned upon storage creation, so that I have full control from the outset.
    Context: Immediate ownership clarifies user authority.
    Issues: #43

  • Performant Access Control
    As a user, I want access control mechanisms that are responsive and scalable, so that the system performs well even under heavy load.
    Context: Performance is critical for large-scale use.
    Issues: #72, #153, #71

  • Clear Error Messages
    As a user, I want error messages that are clear and actionable, so that I can resolve issues quickly and without frustration.
    Context: Good error handling enhances user experience.
    Issues: #34


2.3 Technical Stories

2.3.1 Identity Authentication and Trust

  • Identity & Credentials Management
    As a user, I want to manage my identities and credentials locally, so that I control my authentication process directly from my device.
    Context: Local management boosts security and autonomy.
    Issues: #25, #90, #115, #153, #128

  • Authentication Mechanisms
    As a user, I want support for modern authentication methods like passkeys, silent authentication, and script-friendly options, so that I can authenticate securely across diverse scenarios.
    Context: Flexible authentication meets varied user needs.
    Issues: #39, #41, #49, #50, #51, #114, #162, #129, #130, #136

  • Trust Mechanism for Storage Providers As a Storage Provider, I want a mechanism to trust Identity Providers for authenticating entities, so that I can ensure only authenticated and authorized entities access the storage.
    Context: This trust relationship is crucial for maintaining security in a decentralized system where multiple Identity Providers may be involved.
    Issues: #129

  • Delegation of Control
    As an entity, I want to delegate control of my storage to another entity, temporarily or permanently, so that I can manage access flexibly while retaining the ability to modify or revoke the delegation later.
    Context: Delegation of control enables entities to grant others the ability to manage their storage, which is critical for collaborative or administrative use cases in a decentralized system.
    Issues: #132

2.3.2 API and Protocol Flexibility

  • API Protocol Decoupling
    As a developer, I want APIs decoupled from HTTP, so that I can build local-first applications or use alternative protocols like gRPC or GraphQL.
    Context: Decoupling enhances development flexibility.
    Issues: #24

  • Backend Service Integration
    As a service provider, I want secure authentication methods like mTLS or simpler alternatives for backend services, so that integration with LWS is seamless and secure.
    Context: This ensures reliable backend connectivity.
    Issues: #40, #56, #92

  • Storage Description and Discovery
    As a user or application, I want to retrieve metadata about available storage and service capabilities, so that I can configure interactions appropriately and adapt to different storage behaviors.
    Context: Describing server capabilities in a standardized way allows clients to dynamically adjust their operations, improves interoperability, and facilitates tooling or automation.
    Issues: #21

2.3.3 Storage and Resource Management

  • Globally Unique Identifiers
    As a user, I want all resources and entities to have globally unique identifiers, so that I avoid conflicts and ensure data integrity across systems.
    Context: Unique IDs are foundational for decentralized systems.
    Issues: #108, #115, #160, #66

  • Storage Flexibility
    As a user, I want the ability to dynamically split or aggregate storage units, so that I can adjust capacity and organization as my needs evolve.
    Context: Flexible storage supports scalability and customization.
    Issues: #110, #136, #127, #69, #70

  • Hypermedia Authoring
    As a developer, I want consistent mechanisms for authoring hypermedia representations (e.g., JSON-LD, Siren), so that clients can navigate and interact with APIs uniformly.
    Context: Standardized hypermedia improves API usability.
    Issues: #33, #124


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.