Linked Web Storage Use Cases

W3C Editor's Draft 23 August

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
Editor:
Hadrian Zbarcea
Feedback:
GitHub w3c/lws-ucs ( pull requests , new issue , open issues )

Copyright © 2024-2025 World Wide Web Consortium . W3C ® liability , trademark and permissive document license rules apply.

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 .

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 a 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 that 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 18 August 2025 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. Some use cases in this document may introduce requirements that are de-prioritized or even specifically out of scope for this Working Group. These are retained in this document to support our efforts to do the following:

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 Mechanism(s)

    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

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

  • 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 Access ✓ ✓ ✓

  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.

    Issues: #136 , #108
    Stories: Globally Unique 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 relationships 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.

    Issues: #127
    Stories: Trust Mechanism for Storage Providers

  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.

    Issues: #130
    Stories: Storage Ownership

  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 or revoking it altogether.
    Stories: Delegation of Control

  5. Transfer of Control — The protocol shall allow for an Entity to transfer, i.e. irrevocably reassign control of a Storage to another Entity.
    Stories: Delegation of Control

  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.

    Issues: #140
    Stories: Portable 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.

    Issues: #117 , #124
    Stories: Generic Storage

  8. Data Sharing — The protocol shall allow an Entity to grant 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 or revoking it altogether.

    Issues: #27 , #118
    Stories: Sharing Access, Profile Sharing, Group Sharing, Health Record Access

  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. This log shall include verifiable receipts or acknowledgements when Resources (such as digital goods) are created, modified, delivered, or accessed, ensuring publishers can confirm successful delivery or consumption.

    Issues: #84 , #85 Stories: Administrative Assistant, Legal Reporting, Health Record Access, Digital Goods Delivery

  10. Serialization Format — The protocol shall make it possible for data in a Storage to be serialized in a known format.
    Stories: Data Integration, Personal Information Management

  11. Offline Access and Synchronization — The protocol shall allow Entities to access and modify data even when disconnected from the network, with local changes synchronized to the online Storage once connectivity is restored. This includes providing strong guarantees against data corruption and robust conflict resolution to ensure data consistency after offline edits.
    Stories: Offline Data Access, Storage Listening

  12. Resumable Large Data Transfers — The protocol shall support efficient handling of large files and data streams, including the ability to resume interrupted uploads/downloads. This ensures that network or server interruptions do not force restarting an entire transfer, improving reliability for big file operations.

    Issues: #18
    Stories: Large File Uploads

  13. Data Versioning — The protocol shall support maintaining and retrieving previous versions of Resources. Authorized Entities should be able to recover or inspect earlier versions of data (including metadata and access control states) to enable undoing changes, auditing modifications, or recovering from accidental deletions. This helps ensure data durability and traceability over time.
    Stories: Generic Storage

  14. Notification and Eventing — The protocol shall provide a mechanism to notify relevant Entities of significant events, such as changes to Resources or updates to access permissions. For example, if access rights on a Resource change or new data is available, the affected parties can be alerted in a timely manner. Notification delivery may be real-time (e.g., push/SSE) or via queued channels (e.g., email or inbox), respecting user preferences and privacy.

    Issues: #32 , #100 , #101
    Stories: Notifications for Permission Changes, Real-Time Notifications, Application Notifications

  15. Access Request Handling — The protocol shall enable an Entity to request access to a Resource they are currently not authorized to use, and allow the Resource owner (or controller) to review and grant or deny such requests. There should be a standard way for a requester to signal a desire for access and for the owner to be notified and respond. This ensures that data owners can easily share data upon request without preemptively granting broad access.

    Issues: #11 , #28 , #78 , #79 , #92
    Stories: Health Record Access

  16. Delegation of Access Rights — Beyond whole-storage control delegation, the protocol shall allow an Entity who has certain access rights on a Resource to delegate a subset of those rights to another Entity, if permitted by the original owner. Such sub-delegation may be temporary or scoped, and the original grantor (or the Resource owner) shall be able to revoke or modify the delegated rights at any time.

    Issues: #10 , #104
    Stories: Administrative Assistant, Health Record Access

  17. Contextual Access Control — The access control mechanisms shall support context-aware policies. An Entity should be able to impose additional conditions on Resource access based on context such as time windows, location, or group membership status. For instance, a policy could allow access only during certain hours, or only if the requesting party is within a specific role or group at the time.

    Issues: #17 , #65
    Stories: Context-Aware Access Policies

  18. Inter-User Communication — The protocol shall provide a mechanism for users (or their agents/applications) to exchange messages or data directly via their Storages in a standardized way, enabling built-in collaboration without relying on external messaging services. For example, a user should be able to send a message, notification, or invite to another user's Storage (with appropriate authorization), and the receiving user's client can retrieve or be alerted to this message.

    Issues: #22 , #99
    Stories: Universal Communication

  19. Search and Query — Collection of query reqs:

    Stories: Search Functionality, Pagination & Filtering, SPARQL Queries

  1. Self-Descriptive and Discoverable APIs — The protocol shall include means for Services to discover available capabilities and navigate a Storage's data and access control interfaces uniformly. This way, Services can store, read, update, and delete their data within user-managed Storages, so that Users retain data ownership and sovereignty over app-generated content. This could be achieved via hypermedia controls or standard descriptors in responses (e.g., JSON-LD links indicating available actions or endpoints). Servers should provide a discoverable description of their supported protocol versions, extensions, or features.

    Issues: #12 , #21 , #70 , #120
    Stories: Storage Description and Discovery, Bring-Your-Own-Data Apps

  2. End-to-End Encryption — The protocol shall enable end-to-end encryption of data such that data stored or transmitted is unreadable to anyone except the authorized parties. Even Storage Providers or network intermediaries cannot decrypt the content (only the data owner and intended recipients can). End-to-end encryption should be achievable for data at rest and in transit, using standard algorithms.

    Issues: #4 , #44
    Stories: End-to-End Encryption

  3. Data Integrity Verification — The protocol shall incorporate mechanisms to ensure and verify the integrity of stored data. Authorized Entities should be able to detect if data has been tampered with or corrupted (whether at rest or in transit). For example, the system may use cryptographic hashes, signatures, or checksums so clients can confirm that a Resource retrieved from Storage is exactly as originally stored by the owner.
    Stories: Legal Reporting

  4. Consent-Based Data Sharing —

  1. Legal Basis Enforcement — The protocol shall support associating access control decisions with legal bases or policies. For example, implementers should be able to tag data access rules with specific legal grounds (such as "Consent – GDPR Article 6(1)(a)" or "Contract – GDPR Article 6(1)(b)"), and record these as metadata alongside audit trails.

    Issues: #80 , #77
    Stories: Legal Grounds Support

  2. Authentication Mechanisms — The protocol shall support centralized, federated, and self-sovereign types of authentication mechanisms.

    Issues: #25 , #90 , #115 , #128 , #39 , #49
    Stories: Identity & Credentials Management, Authentication Mechanisms

  3. Trusted Identity Providers — The protocol shall enable Storage Providers to establish trust relationships with Identity Providers of their choosing, rather than blindly accepting any identity source. Trust is non-transitive: a Storage only accepts credentials from IdPs it explicitly trusts.

    Issues: #129
    Stories: Trust Mechanism for Storage Providers

  4. Loose Coupling of Underlying Protocols — The core data access and identity interactions shall be defined abstractly, decoupled from any single transport or encoding. While HTTP(S) is expected, the protocol's semantics must be mappable to alternative transports (e.g., gRPC, GraphQL over WebSocket, local IPC) without changing its fundamental model.

    Issues: #24
    Stories: API Protocol Decoupling

  5. Server-to-server Authentication — The protocol shall support secure authentication and authorization flows suitable for server-to-server and backend service integration enabling trusted services to access user Storages without interactive login. Possibilities include mutual TLS, signed JWT-based service credentials, and/or scoped long-lived tokens.

    Issues: #40 , #92
    Stories: Backend Service Integration

  6. Scalable Storage Management — The protocol shall permit flexible management of an Entity's data across multiple storage units or providers, allowing logical unification of disparate back-ends. Clients should experience a single coherent Storage view even if data is split or migrated across providers, supporting scenarios like jurisdictional partitioning or provider failover.

    Issues: #110 , #136
    Stories: Storage Flexibility

  7. Performance and Scalability — The protocol and its implementations shall be designed for high performance at scale. Access control checks and data operations should incur minimal overhead, and the design should allow batching, caching, and distributed/clustered deployments to meet typical web performance needs.

    Issues: #72
    Stories: Performant Access Control

  8. Profile Management — The protocol shall support Entities having multiple distinct Profiles (e.g., "work" vs. "personal"), each with its own identifiers, metadata namespaces and access-control rules, so that data can be selectively shared under different personas.
    Stories: Profile Sharing

  9. Group-Based Access Control — The protocol shall allow Controllers to define and manage Groups of Entities, apply access control rules at the group level, and propagate membership changes dynamically so that permissions update automatically as the group evolves. This protocol should also allow for group hierarchies, e.g., Solid-admin can be defined as a subset of Solid-contributors, so all permissions given to Solid-contributors also apply to Solid-admin.

    Issues: #38 , #102
    Stories: Group Sharing

  10. View-Based Data Sharing — The protocol shall enable Controllers to define and expose derived "views" of a Resource (e.g., filtered, aggregated or redacted subsets) such that recipients see only the authorized slice without duplicating the underlying data.

    Issues: #63 , #106 , #116
    Stories: Sensor Data Sharing

  11. Federated Data Queries — The protocol shall support Clients performing queries across multiple Storages (including SPARQL federation), aggregating and returning results transparently while enforcing each Storage's access controls. controlss.

    Issues: #88
    Stories: Data Integration, SPARQL Queries

  12. Collaborative Editing — The protocol shall define optional mechanisms (e.g. locking, optimistic concurrency or CRDT-based merges) to allow multiple Entities to co-author or edit the same Resource concurrently, with built-in conflict detection and resolution.

    Issues: #146
    Stories: Semantic Collaboration

  13. Timeseries Data Support — The protocol shall include primitives for storing, querying and aggregating timeseries Resources—supporting configurable resolution limits and multidimensional analysis for data like IoT streams or metrics.

    Issues: #6
    Stories: Timeseries Storage

  14. Self-Describing Website Publication — The protocol shall support publishing self-describing websites with persistent URIs directly from a Storage, enabling durable, interoperable content hosting.

    Issues: #31
    Stories: Website Creation

  15. Profile Interaction UI — The protocol shall define a standard method for clients to fetch and display an Entity's profile (e.g., WebID), along with supported actions (follow, message, share), so users can engage seamlessly with contacts.

    Issues: #47 , #48
    Stories: WebID Profile Interaction

  16. Personal Data Projection — The protocol shall provide a mechanism to support automatic transformation (projection) of personal data into formats consumable by non- LWS applications (e.g., JSON, vCard), without duplicating underlying resources, to prevent data silos and provide compatibility/interoperability with existing Web standards. (This may also apply to converting from one LWS data schema or structure to another, for interoperability across LWS applciations.)

    Issues: #2
    Stories: Personal Information Management

  17. Authorization Capability — The protocol shall provide mechanisms for authorizing and unauthorizing resources in the Storage. The Owner shall be able to set different access permissions for different users, alicnets, services, etc. The authorization may be verified by other permitted Services as well.

    Issues: ... #92

, #120 , #144
Stories: Authorization

  1. User-controlled Protocol Extension : The protocol shall provide standard ways for the Storage Owner (rather than the Service Provider) to configure additional features supported by the Storage. Such additional features are not necessarily operated by the Storage Service, also not necessarily limited to those provided by the Storage Service. Owner may also limit the extensions (i.e. providing less features than the Service provides).

    Issues: #202 , and many UCs (maybe) not classified as essential / classified as out of scope of LWS Spec. For example, alternative data "layouts" #106 , #97 , #98 ; query interface #45 , #152 ; arbitrary forms of policy engine #81 , #82 , #72 , #60 , DToU ; facilitating operations requiring a "service", #3
    Stories: ??? (Extensibility?)

  2. Custom information for Clients — The protocol shall provide a mechanism to allow users to configure custom metadata associated with a resource, and/or custom HTTP response fields when accessing / querying a resource. This will allow a resource to have additional configurable metadata, further usable by Apps / Clients / Services of interest.

    Issues: #94 , #57
    Stories: ??? (Extensibility?)

  3. Anonymous Identity Recognition — The protocol shall provide a way to differentiate between different anonymous users, especially to assign different permissions to them (e.g. creator-based permission).

    Issues: #144
    Stories: ??? (Identity?)

  4. Data Authenticity Verification : The protocol shall provide standard ways to verify that a piece of data is written by a particular User/Identity (e.g. something like a signature). The scope of “piece of data” is yet to be discussed. Ideally, it should be any level; at minimal, it should be a Resource.

    Issues: #138
    Stories: ??? (Integrity)

  5. Data Browsing : The protocol shall provide standard ways for the User / Client to browse (and/or query) the content of the Storage. The browsing had better be in a familiar way (e.g. file-system-like, or knowledge-graph-like).

    Issues: #97 , #98
    Stories: ???

  6. Alternative Data Layouts : The protocol shall provide standard ways for the User / Client to set or request the content of the Storage being presented/used in different layouts, while keeping the original / other layouts. The Client can be transparent about the layouts, or request a specific layout. For example, for a file-system-like layout, it can be by organizing data in a different directory-structure (e.g. from by-date to by-type). Unless for knowledge graphs, this has nothing to do with Resource contents, but just the layout of Resources.

    Issues: #106 , #98
    Stories: ???

  7. Cross-Client Automatic / Simple Log-in : The protocol shall provide a standard way to allow different Clients/Apps to use the same log-in status, saving the User having to click “log-in” when switching Clients/Apps., or at least with a single click (with sufficient information showing the shared log-in status). This should be configurable, to limit what Clients/Apps this applies to.

    Issues: #50
    Stories: ???

  8. Custom Rendering : The protocol shall provide standard ways to allow Storage Owner to configure information / metadata of certain Resources (files, folders, etc) to specify the designated rendering engine / Client / App. Such information / metadata should also allow to be tailored for different types of Clients / Apps / User Agents (e.g., browser can select HTML view; if not HTML view is configured, but a special browser extension installed, use a specified custom App to render it instead).

    Issues: #31 , #47 , #48 , #57
    Stories: ???

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.