[UC] Non-owner can use an app of their choice to access data shared with them

[mrkvon]

As a person (Alice) participating in a Social Network/Online Community,
I want to use an app of my choice to access the data shared with me,
So that I can benefit from the social features without vendor lock-in.

Related to #17 (comment)

This is the case for allowing data non-owners to choose what app they want to use within the scope of their permission, as opposed to data owner choosing the app for them.

Preconditions:

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

A social network on top of LWS, where Bob can give other people (e.g. read) access to his data.

Trigger:

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

Bob shares his data with Alice or an Online Community that they both are members of, using a Mainstream App.

For example:

• Bob shares information about him with the Online Community.
• Bob shares certain resources (e.g. mapping points) with the Online Community or Alice.
• Bob writes a message for Alice in his data storage.
• Alice wants to write something to Bob's inbox.

Actors:

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

• Bob is a data owner
• Alice is a person that Bob granted access to his data, e.g. read access
• Online Community is a group of people that Bob has granted access to his data.
• Mainstream App is an app that many members of the Online Community use, including Bob.
• Niche App is an app that a smaller portion of members of the Online Community use, including Alice. It might be new, improved in some way, perhaps offer accessibility features that Mainstream App doesn't, etc.

Distinction:

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

Scenario:

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

Bob uses a Mainstream App with mapping capabilities to share his favourite spot in a park in the town with Alice and Community, but not publicly (doesn't want the park to get crowded).
Alice can use a Niche App to see the shared spot on the map, and doesn't need to ask Bob for a special Niche App permission. Bob doesn't need to even know about the Niche App.

This allows each actor with sufficient access to choose what app they want to use, and prevent vendor lock-in. (i.e. if most people use Mainstream App for the social data sharing features, everybody else must use Mainstream App). This is particularly important in a context of online communities where it's not feasible for everybody to give special permissions to every app any other community member may want to use.

The case for sensitive data managed in this way:

Bob shares sensitive medical data with Dona, his doctor via a patient app. Dona uses an app for medical professional, to access data of all her patients. Bob doesn't need to know what app Dona uses, but she should still have access via her custom app, and also switch to a better app without all her patients' involvement.

Alternative case(s):

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

Error scenario:

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

Acceptance Criteria:

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

References:

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

SolidCouch is a Solid-based hospitality exchange web app where hosts can share an approximate location of their home with others, and travellers can access the offers on a map, and write to hosts in the area. The data sharing is based on acl:accessGroup feature of WAC. Many community members use Node Solid Server pods, which rely on acl:trustedApp predicate to limit data access to certain origins. When the main app that everybody has been using breaks, gets outdated, or say goes behind a paywall and members slowly start using an alternative app or apps, these NSS-based members disappear from the map. This is a significant issue, since it gives too much power in hands of the original app creators. This has been a repeated issue in the hospitality exchange communities. It also partially recreates the issue of walled gardens which Solid tried to fix in the first place.

The same goes for Solid Chat. The person hosting the chat would have to approve every chat app any other participant uses before they can participate.

People in the Solid community who have been writing specifications, sometimes discuss and propose alternatives to acl:trustedApp, and new mechanisms for application permissions, but it seems to me (without deeper research) that these tend to be data-owner centered, and don't take into consideration the issue of the resulting social app vendor lock-in described here.

Within the context of acl:trustedApp and NSS, a straightforward solution would be for the NSS data store to respect the trusted apps of authenticated agent, instead of trusted apps of data owner; or either of the two.