Hi! I am new to solid development and something is not clear to me so I want to ask if I understand it right.
So suppose an application knows the WebID of a person. The app doesn’t require any user to authenticate himself so there is no authentication token, it just knows the WebID. Can it use the fetch method for that WebID to retrieve data from the pod? If I am correct only if the user has defined in his pod that the app is trusted and can read his data, only then the data will be returned to the app. Is the process I described correct? Or the app needs to provide extra data?
Hi Athina,
It depends on what permissions have been set for that data. If the data is public, if can use the browser’s regular fetch method to fetch the data. If data is restricted such that only specific people can see it, then those people will have to be authenticated in the app, and the app will need to be marked as trusted by that user. (Though the trusted apps functionality is likely to change in the future.)
1 Like
@Vincent So it is not possible for application to act as a service and periodically ask data from a specific pod, if the user trusts the application to have access to read his data? Always there must be a user behind an application that makes the requests and previously authenticates himself?
Also if I understand it correctly, only the user can make requests to retrieve data from his pod, and he can do that through an application that requires him to authenticate first.
It is not possible for a user A to request data from the pod of user B, even if the user B has set that the application is trusted and that the WebID of A has permission to read data from B’s pod. Right?
This is breaching the limits of my knowledge, so take this with a grain of salt. But no, the trusted apps mechanism is not intended to serve this use case, however, the use case case of a bot acting on behalf of the user is certainly in scope, and I believe there are people working on making sure that that is supported. I can’t give more specifics on that, unfortunately.
Unfortunately, I also don’t know the answer to your last question. I think user A should mark that application as trusted rather than B, but I’m not sure.
But A wants to read B’pod so B should set in his pod that the WebID of A is able to read his data and also that the application that A uses is one that B trusts.
Do you happen to know if that is right? Thank you for your time and answers 
Unfortunately I don’t know, but I think that B should configure that A is able to read their data, but A can choose which app they trust to do so. But again, I may be wrong there.
You can authorize solid pod A to have certain controls over your solid pod. Unfortunately, app authorization is not a more refined set of permissions at this time. If I give your pod permission to read and write to my solid pod, then it is across the board permission, and not limited to a specific URI. You can give a WebId permission to read, write, append to a certain file (URI).
Unfortunately, a flaw in the system is that if you give an app permission to interact with your pod, lets say you give an app read, write and append privileges, you are essentially giving that App permission to do almost anything it wants, including but not limited to, potential militias acts.
What I would hope to see in Solid is, a set of permissions that expires when you log out of the app you were using. I do not personally like that I have to grant an app permission unilaterally to interact with my pod anytime it wants to, even when I am not using the app I gave permissions to.
Think of it like this also, you give a URL permission to interact with your pod, and then that app you gave permission to changes its code, and added more features, your pod does not know that certain changes have been made giving an unfair advantage of the app over your pod could be problematic.
We have to consider that an application is not just machine to machine but, the human element interacting with the machine permissions could be abused so, granting unilateral permissions to an app does not mean that the employee of the app could not do something nefarious.