OK, so I think I’m seeing a lot of discussion on this forum circle around two sides of one issue that seems like SOLID does not address it adequately yet:
- putting data in specific folders
- allowing apps to access only those folders
Apps are just views on your data, and they act as a user agent. This means that the way SOLID uses OIDC is kind of special: it is not the app that is requesting to know who the user is; it is the pod that wants to know which user is represented by the app. The app is not the end consumer of the proof-of-identity that OIDC provides; the app just passes it on to the pod, on behalf of the user. I currently see two ways to use SOLID:
- give the app root access
- the app has a WebID that is mentioned in some folder’s .acl file
And I would like to propose a third - using the OIDC flow, but not giving root access:
- maybe the consent form could ask additional questions, for instance ‘read-only or read/write?’ and ‘only to /private/contacts and /private/pictures, or to all of /private?’
2 Likes
each app needs its own mask of permissions?
1 Like
not sure if i understand your question, but suppose I want to use a slides viewer for a presentation, even if there is no well-known place for slides on a pod, then I would like to select ‘/presentations/2018/utrecht-solid-meetup-lightning-talk, read-only’ in the consent dialog, meaning the slides-viewer cannot vandalize my data or crawl any of my data outside the slides folder i’m viewing with it.
https://github.com/solid/webid-oidc-spec#benefits-and-capabilities mentions that webid-oidc sets up the infrastructure for adding Capabilities functionality to Solid - I wonder if that refers to tahoe-lafs-style “read/write caps” and whether it’s meant to mean something along the lines of subfolder permissions?
Now I’m thinking about it, a user could add a sort of ACL manager pane to their pod, that acts as the consent form in an OAuth dance. When you grant access, an identity URL is created for the app, sort of like a visitor id badge. This guest identity is then mentioned in .acl files (the pane edits those), and the app is given an OIDC bearer token for it. I’ll think this through a bit more and see if I can implement a PoC of such a pane…
1 Like
IMO changing changing ACL shouldn’t require IRI of ACL controlled resource to change. Personally I find idea of using /public or /private very brittle and most likely leading to broken links due to changing permissions. AFAIK google drive gives opaque unique IRIs to resources and keeps all folder and permission related information as part of the data, and changing them doesn’t result in IRI denoting the resource changing as well.
Web ACL allows creating permissions specific to app origin which creates some challenges on its own. I think preferably I should give certain permission to another agent and that agent should have a way to create more specific permissions for the apps they use (preferably indiehosted on origin they control). Maybe we could have standard property (~ link relation) that relates agent to the app they use for granting permissions to other apps and when we give access to agent we just give access to that specific (discoverable from their WebID Profile) app. Having that other apps can request permissions to resources which agent can approve / reject using their discoverable ‘permissions granting’ app.