Skip to content
This repository has been archived by the owner on Apr 13, 2022. It is now read-only.

[discuss] how to give an app access to only some of your data #150

Open
michielbdejong opened this issue Mar 28, 2019 · 3 comments
Open

Comments

@michielbdejong
Copy link
Contributor

WAC allows the user to specify access through lists of access control rules, granular to:

  • path (which container or resource is the ACL rule about)
  • agent (which webid or group of webid's gets this access)
  • origin (when accessed from a browser, which origin header is required)
  • access mode (read-only, append-only, write, or control)

This is great if the user knows which containers/documents an app needs access to, and if you know which of your documents you want to prevent this app from accessing. On today's weekly call, @aveltens mentioned configuring his pod so that the MarkBook app could only access bookmarks and nothing else, but it was a lot of work, and this is probably only a viable workflow for a power-user.

Let's get together and discuss how we can improve this situation. We might use this github issue or move this discussion elsewhere at some point, with the goal of producing some sort of solution for this.

@elf-pavlik
Copy link
Member

elf-pavlik commented Mar 28, 2019

I see it worth to always keep scenario of various group / organizational shared storages. In that case WAC on resources should only address which agents have access to which resources. Every and each of those agents should have independent way to define any app specific details.
It might come tricky to make server hosting that group shared storage to rely on all those personalized app access configurations, especially if we might not find a way to always have them public. In case of private app access configurations it might require each person to have app use personal proxy which would act on behalf of that person (possibly WebID delegation) and take all the responsibility for that person's app specific access constraints. This proxy could have access to all that configuration without requiring making it public since all the servers hosting various groups shared storages will not need access to it.

@gobengo
Copy link

gobengo commented Mar 28, 2019

I will also throw in a related idea. Ignoring the specifics of solid, what I want from my own personal cloud is to be able to try out apps that I don't quite trust yet. Let's say I'm on my laptop and some app wants to access my SongListens collection. I don't want to have to authorize the whole collection before I get any value from this app (e.g. because it can build a behavioral profile from me a la Cambridge Analytica).

At first I want it to have to explicitly ask for things. So I'm on my laptop and I give this app my Identity URL (e.g. solid pod), I'm in, and I can start clicking around the app, which will progressively ask for more authorization over time, both as I click around the app, and asynchronously as it tries to keep track of my SongListens as they happen. All I really want to authorize at this time is to let this untrusted app see that I listened to a song, i.e. it can find out when the cardinality of my SongListens collection has changed. I don't even want to consent to this app being allowed to store anything about me other than my ID URL for any period of time, but I would be willing to let them store the history of cardinality changes to this collection, nothing more yet.

The next day I go for a run and start listening to music or podcasts. After the run, I check my phone. I want to have a push notification being like "SongTracker would like to access your SongListens from the last hour" . Depending on my mood, I can click yes or no. Let's say I click yes, and it want to contribute some recommendations as a playlist for my next run (after taking a few minutes to build an ML model or something, or just to space out its authorization requests).

Later in the day, I check my phone: "SongTracker has made you a playlist! Can they write it to your Playlists folder?". I hit yes (for this one time action). They don't need to see my other playlists. They don't need carte blanche write access. etc.

Anyway. I hope this illustrates the type of "Asynchronous Progressive Authorization" that I want in my life, and maybe others will too. I hope that solid authorization vocab, protocols, and flows can enable it.

@elf-pavlik
Copy link
Member

I think app permissions should work together with delegation solid/web-access-control-spec#9 I also see it having similar patter, person's WebID gets included in WAC of some resource, that person can delegate access to some automated agent - delegatee (eg. bot running in a cloud) without modifying WAC of that resource - which in many cases person will not even have control access to.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants