Open pheyvaer opened 1 year ago
Apart from general design, the external service will need to be authorized to read/write resources on the user's pod. Currently, there seems to be mainly 3 possibilities:
The 3rd way seems to be the most promising if we need to implement it soon and does not want to depend on ESS specifically. I believe it is related to the "bot" choice on SolidOS/Mashlib's permission pane, so probably works on all Solid implementations.
Since I never used this before, I'm not sure how hard or easy each choice would be in terms of complexity? In particular, what is the right library to use or the right data to carry (if no existing libraries) if the service wants to do this? Are there any other concerns that need to be taken care of?
Credit @zimengzhou1 for finding the two documents.
1) Yes indeed. The token gives full access to the pod. 2) This would tie the service to ESS, which also applies for option (1), but we have alpha proof-of-concept code that allows developers to get client credentials of both CSS and ESS using the same API. 3) This can work but the problem here is that logging in with a WebID requires browser interaction and has to happen very often. This would mean that you somehow have to get that in your service and the owner of the service will spend their days logging in.
Personally, I would go for option (1) because if you run the service in a controlled environment yourself it should not be a (big) issue. If this would be a public service offered by a third party, then we are talking about something else.
@pheyvaer Willing to take on this challenge!
Apart from general design, the external service will need to be authorized to read/write resources on the user's pod. Currently, there seems to be mainly 3 possibilities:
What about just doing an automated authorized request, following the Solid protocol? I.e., make the service an agent with a WebID, give permission to that agent.
One of the goals with the challenge is to see how a service can act as a given WebID. That way you can give a person's WebID access to a resource and use a service to act on behave of that person without having to know about the service doing it. For example, I can give a give a person write access to a resource on my pod, but I don't care what service or app they use to write. Giving a service write access through its WebID would give it write access regardless of the person writing, which is not what you might want.
@pheyvaer Perhaps the "on behalf of" would be a good subchallenge? Because this challenge can be satisfied by assuming a service-specific WebID.
I've updated the acceptance criteria of this challenge.
FYI this issue is about how you configure the service. How the service actually works (including the access part) is challenge #68.
Pitch
Challenge #68 is about the back-end part of having an external service that stores calendars in a pod. Initially, it will be launched and configure on the command line, but there is also a need for non-tech users to configure this external service. For this we will need a graphical user interface.
Desired solution
A solution could be a website tied to the back-end service that allows to configure it. A user logs in with their WebID and defines which calendars are stored where in their pod. It's worth investigating to store the configuration of the service on the pod of the user.
Acceptance criteria
Pointers
Scenarios