Linked Web Storage Use Cases

The LWS specifications aim to enable the development of web applications where data storage, entity authentication, access control, and application provider are all loosely coupled, as compared to the web of today where these are typically all tightly coupled, so changing one requires changing all, sometimes at a cost of all past data.

This document lists user stories and use-cases for the LWS specifications, as well as requirements identified as necessary to satisfy these use cases.

The use cases for the LWS specifications are documented below.

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

   Issues: #84
   Stories: Administrative Assistant, Legal Reporting, Health Record Access

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 — The protocol shall support querying of data to help users and applications discover Resources based on content or metadata. It shall offer powerful search capabilities (e.g., full-text or attribute-based search) while enforcing access controls on results. 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.

    Issues: #45, #103, #152
    Stories: Search Functionality, Pagination & Filtering, SPARQL Queries

20. Self-Descriptive and Discoverable APIs — The protocol shall include means for clients to discover available capabilities and navigate a Storage's data and access control interfaces uniformly. 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: #21, #70
    Stories: Storage Description and Discovery

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

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

23. Consent-Based Data Sharing —

• The protocol shall provide a means to record and honor user consent for data sharing, including details on who, what, purpose, and duration.

• There shall be a verifiable, auditable record of consent (e.g., receipts or tokens) that is revocable, ensuring access removal upon withdrawal.

  Issues: #141, #81
  Stories: Consent-Based Sharing

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

25. User-Centric Identity Management — The protocol shall integrate with identity systems in a way that empowers users to control their credentials and identifiers. Users should be able to manage self-sovereign identities or locally stored credentials and authenticate to a Storage using an identity solution they trust, accommodating standards like decentralized identifiers or client-managed credentials.

    Issues: #25, #90, #115, #128
    Stories: Identity & Credentials Management

26. Modern Authentication Methods — The protocol shall support contemporary web authentication methods, such as passkeys or WebAuthn for passwordless login, "silent" non-interactive flows for scripts, and client-credentials or token-based auth for automation. All methods must result in a verified Entity identity recognized by the Storage.

    Issues: #39, #49
    Stories: Authentication Mechanisms

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

28. Protocol Binding Independence — 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

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

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

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

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

32. Clear Error Messaging — The protocol shall specify clear and standardized error messages for various failure conditions, including meaningful status codes and human-readable information indicating the cause and possible remediation.

    Issues: #34
    Stories: Clear Error Messages

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

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

    Issues: #38, #102
    Stories: Group Sharing

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

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

    Issues: #88
    Stories: Data Integration, SPARQL Queries

37. Delivery Receipts — The protocol shall provide a mechanism for sending 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: #85
    Stories: Digital Goods Delivery

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

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

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

41. Network Flexibility — The protocol shall ensure Storages remain accessible from home or mobile environments with dynamic IPs or NAT, providing mechanisms (e.g., NAT traversal, DNS aliasing) so connectivity isn't impeded by changing network endpoints.

    Issues: #105, #68
    Stories: Home Access

42. Bring-Your-Own-Data Apps — The protocol shall enable third-party applications to store, read, update, and delete their data within user-managed Storages, and to discover available Storage capabilities, so that users retain data ownership and sovereignty over app-generated content.

    Issues: #12, #120
    Stories: Bring-Your-Own-Data Apps

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

44. Personal Data Projection — The protocol shall support projection or transformation of personal data into formats consumable by non-LWS applications (e.g., JSON, vCard), without duplicating underlying resources, to prevent data silos.

    Issues: #2
    Stories: Personal Information Management

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 — TBD
• 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 NIST definition
• Notification Service — TBD
• 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 — description
• Storage Service — TBD
• Storage Provider — TBD
• User — A human entity; see NIST definition.
• User Agent — Software acting on behalf of a user to interact with services, such as a browser or identity client.