As a regular user,
I want to securely store linked data in my LWS storage, such as storing encrypted linked data,
So that I can safely store any sensitive data even on a not-fully-trusted storage provider.

Preconditions:

What conditions must be in place or assumed before this use case can begin?

The user (Alice) has concerns on the data safety during LWS usage, due to either:

• She does not entirely trust the Solid service provider;
• She does not entirely trust the underlying cloud storage provider;
• She does not entirely trust the App environment;
• She holds a very strong opinion that this part of the data should be encrypted until needed (e.g. password store);
• ...? (Any more?)

I'm writing "encryption" hereafter for the secure storage of data, as it's the only mechanism I can think of.

Trigger:

What (user or system) event or action initiates this use case?

• The store intends to store sensitive data in the storage

Actors:

Describe the primary actor, and any other relevant actors involved in this use case

• User (Alice): who "owns" the storage, and interacts with the Apps
• App: storing and retrieving some data to and from the storage
• Non-obvious actors:
  • LWS service provider
  • Underlying storage provider

Distinction:

What unique challenges or distinguishing factors (like technical issues, user experience needs, workflow integration, etc.) are associated with this use case?

In a regular scenario, we believe/assume 1) the storage is fully trustworthy, 2) the App is fully trustworthy, and 3) access control is enough to restrict App to the region is it trustworthy to.
However, here, we assume these assumptions can all be broken (one by one, or multiple together). One distinct scenario is when the App is somewhat trustworthy but not entirely, but it needs to be granted permission to read/write to a large range of data in the Pod.

For example, a Pod- / file-manager App should be granted permission to the whole Pod; in the meantime, Alice stores her password or diary in her Pod, whose raw content should not be exposed to the Pod-manager App, while it is fine for the Pod-manager App to see their existence and modify their permissions and/or moving them around.

Scenario:

Describe an ideal or happy-case scenario where this use case would play out as intended.

1. Direct resource access (read/write/control) works for the data:
   1.1. Be able to retrieve / write to the secure data without seeing its contents (i.e. modifying the encrypted form);
   1.2. Be able to retrieve / write to the secure data's actual contents (i.e. modifying the decrypted form), if sufficient passkey is provided;
2. Queries and lookup (e.g. SPARQL, Type Index, or alike) work for the data:
   2.1. Can be performed on the encrypted form;
   2.2. Can be performed on the decrypted form (if sufficient passkey is provided);
3. No additional special cares should be taken from the App (apart from using different functions and/or supplementing different arguments), unless it intends to play with the internal of the mechanism.
4. Alice can share the encrypted data to another user, and provide a different passkey to decrypt it

Alternative case(s):

What alternative flows or variations should the system handle for this use case?

• Positive:
  • Support multiple passkeys for different content
  • Support multiple levels of decryptions (i.e. level 1 must be decrypted before level 2 is decrypted)
  • Support telling if a resource is encrypted or not
  • Support encrypting a container
• Negative:
  • Some type of queries can be skipped, if it is proven difficult
  • Some additional cares can be taken from the App, but it should not require the App to implement/handle everything from scratch (otherwise this use case is not fulfilled -- it would be the same as the normal expectation)

Error scenario:

What unexpected issues or errors might arise, and how should the system handle them?

• Wrong passkey is provided: treat as if not supplementing a passkey, and keep the file encrypted
• Writing unencrypted data to an encrypted resource: not sure if we should prevent this (i.e. requiring deleting first) to avoid accidental overriding of contents

Acceptance Criteria:

What conditions or criteria must be met for this use case to be considered successfully handled? What limitations are acceptable?

• Happy scenarios are all supported; or
• Negative "alternative scenario" is well-reasoned and thus not supported

References:

List any relevant resources or examples that could inform this use case, possibly from other domains or solutions.

Not really, but just some inspirations on why this may be useful:

• E2E encrypted cloud drive like Mega, also supporting file sharing
• Password manager with encryption like pass