Linked Web Storage Use Cases W3C Group Note Draft 10 February 2026 More details about this document This version: https://www.w3.org/TR/2026/DNOTE-lws-ucs-20260210/ 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-2026 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 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 a Group Note Draft using the Note track . Group Note Drafts 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 a work in progress. The W3C Patent Policy does not carry any licensing requirements or commitments on this document. This document is governed by the 18 August 2025 W3C Process Document . Table of Contents Abstract Status of This Document 1. Introduction 2. Glossary 3. Use Cases 3.1 Functional Stories 3.1.1 Data Management 3.1.2 Access Control and Sharing 3.1.3 Collaboration and Communication 3.1.4 Application Integration 3.1.5 Advanced Features 3.2 Non-Functional Stories 3.2.1 Security and Privacy 3.2.2 Performance and Usability 3.3 Technical Stories 3.3.1 Identity Authentication and Trust 3.3.2 API and Protocol Flexibility 3.3.3 Storage and Resource Management 4. Requirements 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: Develop an LWS standard that enables future technologies which do meet these requirements. Provide a common set of use cases to be leveraged in the development of such future technologies. Develop a comprehensive view of the potential of the Linked Web technologies. Clarify which use cases have been submitted, to avoid redundancy, where possible, in future use case submissions. 2. 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. Application — A computer program or set of programs designed to perform a specific function for a user or another entity . Authentication — Verifying the identity of a user , process, or device, often as a prerequisite to allowing access to resources in a system; see NIST definition . Authorization — The process of verifying that a requested action or service is approved for a specific entity ; see NIST definition . Controlled Identifier — A type of identifier that can be proven to be under the control of an entity ; see W3C CID definition . Controlled Identifier Document — A document that contains cryptographic material and lists service endpoints that can be used for verifying proofs from, and interacting with, the controller of an identifier ; see W3C CID definition . Controller — An entity that is capable of performing an action with a specific resource, such as updating a protected document. Entity — An individual (person), organization, device, or process. Used interchangeably with “party”; see NIST definition . Identifier — The bit string denoting the identifier associated with an Entity ; see NIST definition . Identity Provider — A service provider that operates an identity service . Identity Service — A service that manages the subscriber’s primary authentication credentials and issues assertions derived from those credentials; see NIST definition . Non-human Entity — An entity with a digital identity that acts in cyberspace, but is not a human actor. This can include organizations, hardware devices, software applications, and information artifacts; see also NIST definition . Notification Service — A service that delivers asynchronous or real-time messages to an entity regarding significant changes or events within a subscribed resource or service . Owner — An entity that is considered to have the rights and responsibility of a resource. Profile Document — see Controlled Identifier Document . Profile Document Address — The URL of a profile document . URLs are defined as the "physical addresses of objects which are retrievable using protocols already deployed on the net"; see W3C Addressing definition . Relying Party — A non-physical entity that trusts an identity provider for authentication ; see also NIST definition . Self-Sovereign Identity ( SSI ) — A digital identity that an entity directly controls, without relying on a third party. Self-Sovereign Identity ( SSI ) Owner — An entity that fully manages its own Identity credentials without relying on external service(s) . Service — An abstract resource that represents a capability of performing tasks that form a coherent functionality; see W3C Glossary . Service Provider — An entity providing a service ; see W3C Glossary . Storage — The system or location that provides the capability for the retrievable retention of digital resources (data); see also NIST definition . Storage Service — A service that provides the capability for persistent maintenance and management of digital resources for an entity . Storage Provider — A service provider that operates a storage service . User — A human entity ; see NIST definition . User Agent — Software, such as a browser or identity client, acting on behalf of a user to interact with service(s) . 3. Use Cases The use cases for the LWS specifications are documented below. 3.1 Functional Stories 3.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 3.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 3.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 3.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 3.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 3.2 Non-Functional Stories 3.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 3.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 3.3 Technical Stories 3.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 3.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 3.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 4. 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 ✓ ✓ ✓ 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 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 such delegation at a later time, by changing the expiration time or revoking the delegation altogether. Issues: #27 , #118 Stories: Sharing Access, Profile Sharing, Group Sharing, Health Record Access Authentication Mechanisms — The protocol shall support centralized, federated, and/or self-sovereign types of authentication mechanism. Issues: #25 , #90 , #115 , #128 , #39 , #49 Stories: Identity & Credentials Management, Authentication Mechanisms 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). Further, a Resource may be identifiable via multiple, distinct identifiers. Issues: #136 , #108 Stories: Globally Unique Identifiers 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 dynamically propagate membership changes so that permissions update automatically as the group evolves. The protocol should also allow for group hierarchies (which may also be thought of as nested groups), 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 Delegation of Control — The system shall allow an Entity to delegate control of a Storage to another Entity. Such delegation could be temporary — i.e., have an expiration date & time — or permanent — i.e., have an expiration date of "never" or similar. An Entity shall be able to modify their delegations at a later time, such as by changing expiration or revoking the delegation altogether. Stories: Delegation of Control Subscribing to resource changes (notifications) — 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 made 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 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 scoped long-lived tokens, among others. Issues: #40 , #92 Stories: Backend Service Integration 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 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; this controller may be an abstract entity such as a group, rather than necessarily being an individual person or agent. Issues: #130 Stories: Storage Ownership Self-Descriptive and Discoverable APIs — The protocol shall include means by which Services can discover a Storage's available capabilities and uniformly navigate its data and access control interfaces. This way, Services can store, read, update, and delete their data within user-managed Storages, so that Users retain ownership of data and sovereignty over app-generated content. This might 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, and features. Issues: #12 , #21 , #70 , #120 Stories: Storage Description and Discovery, Bring-Your-Own-Data Apps Use of Service Providers — The protocol shall provide a mechanism by which Entities can delegate some functions to trusted Service Providers. Some interactions might further require a trust relationship between Service Providers and Entities. This should not impede the ability of an Entity to operate or self-host such a service. Also note that trust relationships are not transitive, in the sense that if an Entity trusts a Service Provider, e.g. an Identity Provider, no other 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 Storage Portability — The protocol shall allow for an Entity to port, i.e., copy, move, or transfer, the entire contents of a Storage from one Storage Provider to another. Once a move or transfer is complete, at the Entity's choice, the initial Storage Provider can be freed from any responsibility related to the Storage. Issues: #140 Stories: Portable Storage 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 otherwise scoped, and the original grantor (or the Resource owner) shall be able to revoke or modify the original and thereby subsidiary delegated rights at any time. Issues: #10 [UC] Administrative assistant working for department head , #104 [UC] Access delegation by autonomous groups/organizations Stories: Administrative Assistant, Health Record Access Search and Query — Collection of query reqs: Stories: Search Functionality, Pagination & Filtering, SPARQL Queries pod-level query — SPARQL queries, respecting ACLs to easily find stuff in potentially large pods GET < my-pod-path > /__SPARQL?query=SELECT… Host: < my-pod-server > Issues: #45 SPARQL queries , #152 query (/search) Stories: Search Functionality, SPARQL Queries metadata query — SPARQL queries, respecting ACLs, over server-maintained data e.g., on a root Container: GET < my-pod-path > ?query=SELECT… Host: < my-pod-server > e.g., on a Resource (or nested Container) GET < my-pod-path > / < my-resource > ?query=SELECT… Host: < my-pod-server > resource-level query — query other people's pods, respecting ACLs GET < my-pod-path > / < my-resource > ?query=SELECT… Host: < my-pod-server > query other pods — query other people's pods, respecting ACLs GET < other-pod-path > /__SPARQL?query=SELECT… Host: < my-pod-server > paginate,filter,sort — To handle large result sets, the protocol shall provide features like pagination, filtering, and sorting of query results, and may support standard query languages (such as SPARQL) for advanced semantic queries over the data. This could equally apply to protocol-level query, e.g., GET on an LWP Container Issues: #103 Pagination, filtering and ordering Stories: Search Functionality, Pagination & Filtering, SPARQL Queries federated query — SPARQL queries joining external data, respecting ACLs to easily find stuff in potentially large pods joins across multiple pods — SPARQL queries joining pods, respecting ACLs GET < my-resource > ?query=SELECT…FROM < other-pod-path > … Host: < my-pod-server > Issues: #88 Resource Aggregation Stories: Data Integration, SPARQL Queries joins across multiple resources — SPARQL queries joining external data, respecting ACLs GET < my-resource > ?query=SELECT…FROM < wikidata > … Host: < my-pod-server > GET < my-resource > ?query=SELECT…SERVICE < wikidata > … Host: < my-pod-server > 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 Access Request Handling — The protocol shall enable an Entity to easily request access to a Resource they are currently not authorized to access, and allow the Resource owner (or controller) to easily review and grant or deny such requests. There shall be a standard way for a requester to signal a desire for access, and for the owner to be notified and respond. This will ensure that data owners can easily share particular data upon request without preemptively granting broad access. Issues: #11 , #28 , #78 , #79 , #92 Stories: Health Record Access Consent-Based Data Sharing — The protocol shall provide a means to record and honor user consent for data sharing, including details on whom they are sharing with, what they are sharing, the purpose of the sharing, and the duration of the sharing. There shall be a verifiable, auditable record of user consent (e.g., receipts or tokens) that is revocable, ensuring access removal upon withdrawal of consent. Issues: #141 , #81 Stories: Consent-Based Sharing Data Integrity Verification — The protocol shall incorporate mechanisms to ensure and verify the integrity of stored data. Authorized Entities SHOULD be able to detect whether data has been tampered with or corrupted (whether at rest or in transit). For example, the system may use cryptographic hashes, signatures, and/or checksums such that clients can confirm that a Resource retrieved from Storage is exactly as originally stored by the owner. Issues: Stories: Legal Reporting 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 contexts such as time windows, location, and group membership status, among others. 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 , #179 Stories: Context-Aware Access Policies 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 (though such blind acceptance SHOULD also be a configurable option). Trust is non-transitive: a Storage does not inherit trust relationships; it only accepts credentials from IdPs it is configured to trust (which might be or include a wildcard, e.g., for website content intended for general consumption). Issues: #129 Stories: Trust Mechanism for Storage Providers 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 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. Note that supporting resumption for query-generated datasets may require large local storage, which may mean that resumption is not supported for all deployments. Issues: #18 Stories: Large File Uploads 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 be able to 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 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 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 or future transports (e.g., gRPC, GraphQL over WebSocket, local IPC) without changing its fundamental model. Issues: #24 Stories: API Protocol Decoupling 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 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 Federated Data Queries — The protocol shall support Clients performing queries across multiple Storages (including Federated SPARQL), aggregating and returning results transparently while maintaining each Storage's access controls. Issues: #88 Stories: Data Integration, SPARQL Queries Resource 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 modification audits and change reversion, including recovery from accidental deletions. This helps ensure data durability and traceability over time. Stories: Generic Storage Inbox (notifications) — 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 Personal Data Projection — The protocol shall provide a mechanism to support automatic transformation (projection) of personal data in formats consumable by non- LWS applications (e.g., JSON, vCard), without duplicating underlying resources, to prevent data silos and provide compatibility and interoperability with existing Web standards. (This may also apply to converting from one LWS data schema or structure to another, for interoperability across LWS applications.) Issues: #2 Stories: Personal Information Management 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 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 Self-Describing Website Publication — The protocol shall support publication of self-describing websites with persistent URIs directly from a Storage, enabling durable, interoperable content hosting. Issues: #31 Stories: Website Creation Collaborative Editing — The protocol shall define optional mechanisms (e.g., locking, optimistic concurrency, 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 Timeseries Data Support — The protocol shall include primitives for storing, querying, and aggregating time series Resources, supporting configurable resolution limits and multidimensional analysis for data like IoT streams or metrics. Issues: #6 Stories: Timeseries Storage 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 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 ↑ Permalink Referenced in: Not referenced in this document. Permalink Referenced in: § 2. Glossary (2) Permalink Referenced in: Not referenced in this document. Permalink Referenced in: Not referenced in this document. Permalink Referenced in: § 2. Glossary Permalink Referenced in: § 2. Glossary Permalink Referenced in: § 2. Glossary (2) (3) (4) (5) (6) (7) (8) (9) (10) (11) (12) (13) (14) Permalink Referenced in: § 2. Glossary (2) (3) Permalink Referenced in: § 2. Glossary Permalink Referenced in: § 2. Glossary Permalink Referenced in: Not referenced in this document. Permalink Referenced in: Not referenced in this document. Permalink Referenced in: Not referenced in this document. Permalink Referenced in: § 2. Glossary Permalink Referenced in: Not referenced in this document. Permalink Referenced in: Not referenced in this document. Permalink Referenced in: Not referenced in this document. Permalink Referenced in: Not referenced in this document. Permalink Referenced in: § 2. Glossary (2) (3) (4) (5) (6) (7) (8) Permalink Referenced in: § 2. Glossary (2) Permalink Referenced in: Not referenced in this document. Permalink Referenced in: § 2. Glossary Permalink Referenced in: Not referenced in this document. Permalink Referenced in: § 2. Glossary (2) (3) Permalink Referenced in: Not referenced in this document. Permalink Referenced in: § 4. Requirements Permalink Referenced in: § 4. Requirements Permalink Referenced in: § 4. Requirements Permalink Referenced in: Not referenced in this document. Permalink Referenced in: § 4. Requirements Permalink Referenced in: Not referenced in this document. Permalink Referenced in: § 4. Requirements Permalink Referenced in: § 4. Requirements Permalink Referenced in: § 4. Requirements Permalink Referenced in: Not referenced in this document. Permalink Referenced in: Not referenced in this document. Permalink Referenced in: Not referenced in this document. Permalink Referenced in: Not referenced in this document. Permalink Referenced in: Not referenced in this document. Permalink Referenced in: Not referenced in this document. Permalink Referenced in: Not referenced in this document. Permalink Referenced in: Not referenced in this document. Permalink Referenced in: Not referenced in this document. Permalink Referenced in: Not referenced in this document. Permalink Referenced in: Not referenced in this document. Permalink Referenced in: Not referenced in this document. Permalink Referenced in: Not referenced in this document. Permalink Referenced in: Not referenced in this document. Permalink Referenced in: Not referenced in this document. Permalink Referenced in: Not referenced in this document. Permalink Referenced in: Not referenced in this document. Permalink Referenced in: Not referenced in this document. Permalink Referenced in: Not referenced in this document. Permalink Referenced in: Not referenced in this document. Permalink Referenced in: Not referenced in this document. Permalink Referenced in: Not referenced in this document. Permalink Referenced in: Not referenced in this document. Permalink Referenced in: Not referenced in this document. Permalink Referenced in: Not referenced in this document. Permalink Referenced in: Not referenced in this document. Permalink Referenced in: Not referenced in this document. Permalink Referenced in: Not referenced in this document. Permalink Referenced in: Not referenced in this document. Permalink Referenced in: Not referenced in this document. Permalink Referenced in: Not referenced in this document. Permalink Referenced in: Not referenced in this document. Permalink Referenced in: Not referenced in this document. Permalink Referenced in: Not referenced in this document. Permalink Referenced in: Not referenced in this document. Permalink Referenced in: Not referenced in this document. Permalink Referenced in: Not referenced in this document. Permalink Referenced in: Not referenced in this document. Permalink Referenced in: Not referenced in this document. Permalink Referenced in: Not referenced in this document. Permalink Referenced in: Not referenced in this document. Permalink Referenced in: Not referenced in this document. Permalink Referenced in: Not referenced in this document. Permalink Referenced in: Not referenced in this document. Permalink Referenced in: Not referenced in this document. Permalink Referenced in: Not referenced in this document. Permalink Referenced in: Not referenced in this document. Permalink Referenced in: Not referenced in this document. Permalink Referenced in: Not referenced in this document. Permalink Referenced in: Not referenced in this document. Permalink Referenced in: Not referenced in this document. Permalink Referenced in: Not referenced in this document. Permalink Referenced in: Not referenced in this document. Permalink Referenced in: Not referenced in this document. Permalink Referenced in: Not referenced in this document. Permalink Referenced in: Not referenced in this document. Permalink Referenced in: Not referenced in this document. Permalink Referenced in: Not referenced in this document. Permalink Referenced in: Not referenced in this document. Permalink Referenced in: Not referenced in this document. Permalink Referenced in: Not referenced in this document. Permalink Referenced in: Not referenced in this document. Permalink Referenced in: Not referenced in this document. Permalink Referenced in: Not referenced in this document. Permalink Referenced in: Not referenced in this document. Permalink Referenced in: Not referenced in this document. Permalink Referenced in: Not referenced in this document. Permalink Referenced in: Not referenced in this document. Permalink Referenced in: Not referenced in this document. Permalink Referenced in: Not referenced in this document. Permalink Referenced in: Not referenced in this document. Permalink Referenced in: Not referenced in this document. Permalink Referenced in: Not referenced in this document. Permalink Referenced in: Not referenced in this document. Permalink Referenced in: Not referenced in this document. Permalink Referenced in: Not referenced in this document. Permalink Referenced in: Not referenced in this document. Permalink Referenced in: Not referenced in this document. Permalink Referenced in: Not referenced in this document. Permalink Referenced in: Not referenced in this document. Permalink Referenced in: Not referenced in this document. Permalink Referenced in: Not referenced in this document. Permalink Referenced in: Not referenced in this document. Permalink Referenced in: Not referenced in this document. Permalink Referenced in: Not referenced in this document.