I have setup a solid survey client app where users can answer questions and store their results in their pod. How do I give access to another party, say party B, to use this data and write advice in the person’s pod based on the answers of that person?
In see the following functionality:
→ add user, group, public, anyone logged in, software agent or web app.
So if I want a server application, party B, to get the data from the pod for the persons that allow it, without the user needs to log in in a solid client of party B… how do I do it? And how is this access then managed for that client/frontend-less application? Is that the “software agent” depicted? Can I find documentation on that somewhere?
To @Frederik : in general the owner of data sets rights using the form you show or by sending patches to ACL files. After that any WebId that the owner has given access to can login as themselves and access the data on the owner’s pod without having to anything extra. To see how to use that form, see userguide/README.md at 3a4ac02b2e98519496c5fcf0a64153643e18fcbc · solid/userguide · GitHub. There is also an app flow where the app prompts the user to give rights to the app.
To @Smag0 - ESS is, AFAIK, the only server that implements ACP. The fact that ACP is newer than WAC/ACL does not mean it is or will be implemented everywhere. It does not invalidate or replace WAC, it provides an alternative.
Good point @bourgeoa, you’d think I would have thought of that :-). @Frederik - one strong point about follwoing @bourgeoa’s suggestion is that solid-file-client works either with or without a frontend.
Thanks everybody! Very interesting and helpful. So if I understand correctlty and look at the code, the server application also needs a web Id so it can login and access the resource of the persons who allow it to. The server application needs a “solid client” part to login and access those resources. Jeffz’s solid-file-client can be used to do that as @bourgeoa and @jeffz pointed out. The server application with the solid client needs to do the OIDC/DPoP ceremony to login and get the right access tokens. For this either it needs to pass by a front end to authenticate versus the solid server or it needs to do the ceremony programmatically. Right?
Now comes the second part: a person allows the server application to read a specific part of his/her data by adding the webId to the list of allowed parties, how does this server application knows that it can access it? Therefore a front end is needed so that on the moment the person grants the server app’s webId access, a link is stored in the pod of the server application, which is only readible by the server application. Is writable == writeable && readible or only writeable? Because logically we don’t want other persons to see all the data that has the server access to… Is this the right way to approach it?
You need an authentication client to login to an Identity Provider, e.g. Inrupt’s solid-client-authn. You need that even if you use solid-file-client which provides high level methods to manage and edit files. The authn logs you in and creates an authenticated fetch method, solid-file-client uses that authenticated fetch to perform various operations.
The flow for application access is not settled at this moment. The docs @Smag0 pointed you to will work for the ESS server. The NSS server uses a different method somewhat explained in the trustedApp section of the document I pointed you to above. Your app needs a WebId for ESS but not currently for NSS.
One thing incorrect in your diagram is that it shows an app authenticated to a pod server which only happens if the pod server is also an identity server. Basically, you authenticate and get an authenticated WebId from the Identity Provider then use that to access pods from various pod providers. On each pod, the ACL of ACP methods determine what the WebId and App have access to.
So authentication happens at he Identity Provider, while authorization happens at he Pod provider and is controlled by the user.
