Configure external service that stores calendar in pod

[pheyvaer]

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

1. I navigate to the website tied to back-end service.
2. I log in with my WebID.
3. I configure the service: which calendars are stored where in my pod, including optional transformations. Note that the service acts of behalf of me. It has access to where my WebID has access. It doesn't use a service-specific WebID to determine access to resources.
4. I log out.
5. I can later log in again and make changes to my configuration.

Pointers

• This challenges relies on https://github.com/SolidLabResearch/Challenges/issues/68.
• It's important to think about the user experience: how do you explain the relation between the user, service, and pod.
• IFTTT might serve as inspiration.

Scenarios

[renyuneyun]

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:

1. CSS-specific: this CSS document describes a way to request a token (API key) and use that token for further authentication. It did not mention anything related to authorization, so I assume it means the application has full permission?
2. ESS-specific: this Inrupt document describes a way to request permission to read/write to a resource of a pod for a given period of time for a given purpose. This is experimental and is also ESS-specific at the moment (relies on ACP, an improvement of ACL).
3. User to configure permission in advance by identifying service with a URI (WebID?), and then the service uses that URI (WebID?) as the identifier for authorization. This is similar to how an App acts on behalf of one User to access resources on another User's pod.

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.

[pheyvaer]

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.

[zimengzhou1]

@pheyvaer Willing to take on this challenge!

[RubenVerborgh]

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.

[pheyvaer]

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.

[RubenVerborgh]

@pheyvaer Perhaps the "on behalf of" would be a good subchallenge? Because this challenge can be satisfied by assuming a service-specific WebID.

[pheyvaer]

I've updated the acceptance criteria of this challenge.

[pheyvaer]

FYI this issue is about how you configure the service. How the service actually works (including the access part) is challenge #68.

[pheyvaer]

The code that @zimengzhou1 and @renyuneyun created is here, specifically in the folder app.