Capability Permission Frontend Components

[Laurin-W]

On version 2.0, we are going to have full capabilities generation, with z-Caps (which are compatible with Solid, and that are also used by NextGraph).

For user control, we need frontend components to generate capability-based permissions, to make it easy to share a resource with someone and delegate authority.

[nikoPLP]

I am interested to follow what you will do on that task, as NextGraph has a similar use-case, and we both use semantic data and z-cap, so it would be nice to align our efforts, and maybe even to put the code in common.
As far as I understand, there are 3 parts in the workflow:

• first the app asks for some access on the user's data. this request for access has to detail which part of the data exactly the app wants to read (or write). by example: app wants to read all the minutes of meetings in the container "workshop1".
• then the user needs to receive a notification about this access request, accept or deny. if accepted, a z-cap is generated and sent to the app.
• then the app receives this z-cap, stores it somewhere, and can use it by invoking the capability at a controller (your server). there is a request associated with the invocation (GET, PATCH, etc...). The controller verify the z-cap and replies to the request.

is that how you see it?
i put here some links of a spec of solid about interop, that has some formats for the first step (the access request)
https://solid.github.io/data-interoperability-panel/specification/#access-request

and there is a GUI and backend (both unusable as it is webcomponent and django) that implement those workflow, by the people of Hubl/StartinBlox/HappyDev. Just putting it here for inspiration maybe.
https://git.startinblox.com/applications/trust/interop-app
https://git.startinblox.com/applications/trust/solid-data-dashboard
https://git.startinblox.com/djangoldp-packages/djangoldp-access-grants
https://git.startinblox.com/applications/trust/interop-hubl

I understand that you want to use shape trees in both the access request and the capability.

But I am a little bit concerned that shape trees will be difficult to express in plain english.
In fact, I think the Access request has to be translated into plain english language when presented to the end-user, before they can accept or deny, as in the example i gave above, because we cannot ask the user to review a SHACL file before granting permission.

I had suggested to use the wildcard format "quad pattern selector" of LinkedDataFragment, because it is much simpler, and probably easier to translate into plain english, as predicates and resources all have a label, usually.

Maybe it is not a good idea. Let me know what you think @Laurin-W @srosset81

[nikoPLP]

After talking with @srosset81 on this topic, I understand that you already have implemented something similar with https://docs.activitypods.org/architecture/application-interoperability/

I like what you did with replacing shape trees with a simple list of classes.

I think we could use also this in the zcaps. we shall talk about that later