How do I request a permission to control a specific resource with my app?

[divoplade]

Hello

Suppose I have an app that manages a form of contacts. My app manages private resources, but my user will want to share some managed resources with other users. So, my app should change the ACL of its managed resources. This require the acl:Control authorization.

Instead of requesting full acl:Control over the whole pod, @Smag0 showed me that the user can grant my app control access only over a specific container. The question is, is there a way to programmatically request that specific permission, without having access to the ACL? For instance, redirect the user to user.pod/my-app-container/.well-known/requestControl?app=my-app that would show a page: ‘Would you let my-app control my-app-container? yes/no’

Or of course, anything better that would be discoverable.

I found Sharing files in private folders programmatically (React/JavaScript) which looks relevant but the conclusion was that it was not possible at the time.

[A_A]

@divoplade

The question is, is there a way to programmatically request that specific permission, without having access to the ACL?

No, not that I would know of. Some thoughts:

For now you could just ask the user to (1) give you Control over the whole pod via the data browser, or (2) outsource the sharing to let the user manually do it so your app won’t need Control permissions in the first place.

In the future, I could imagine that the user profile has several linked privileged apps that other apps can forward to. In your case this could be a permission granter app which has Control access and accepts some arguments via the query parameters. But a standard or common implementation for this would be necessary.

As a side note, I’m not sure where trustedApps is evolving to. Currently the limitation only seems to exist for web-apps (it’s based on the Origin header of the app, which isn’t that useful server-side). So one could send the access tokens to some server, make requests from there and essentially circumventing the trustedApp limitation (a bit more detailed here). So I personally don’t see much sense in this setting, but I guess it exists for a reason

[divoplade]

I think the Permission Granter app would be quite beneficial. It could also update your public and private type index so that the app would not even need global read or write permission…

I will try to make some code. Thanks!

[divoplade]

Hello! I have a proof of concept here:

https://divoplade.frama.io/permission-granter-app/

You just need to get /request.html?app=your.app, and if the user agrees it will give you control over a given container that you can discover from the public type index, and there is a rdfs:seeAlso in the profile that points to a resource you control (so that you can put stuff in the profile without modifying it).

However, I am starting to doubt it will be very useful. If you trust the app, I can see no reason to not give it total control instead of “just” total read/write access.

[Smag0]

Bravo !
Because if you give the app full control, it can remove the owner!
This is really what I need with @aveltens groups to Agora

Be careful, if the app folder already exist node solid server give it another name !

• You must specify the user that your permission app must have Full Control
  But that’s a good first shot for a newcomer

[divoplade]

I am still working on it, it is quite buggy ^^

I plan to put all containers in a super-container owned by the permission granter app, and make the URI to create a container discoverable from the public profile. So that the permission granter requires only one manual control setting (if not trusted for global control).

I will also need to find a better name and move the app and the vocabulary to some place outside of my gitlab pages.

[divoplade]

Hello!

• I have trusted the app for read and write globally;
• I have given control access to the app over a specific folder in the ACL (see below).

However, when I try PUTting or POSTing the ACL document of a resource in that specific folder, I get 403 All Required Access Modes Not Granted. Is this a bug? Being able to do this is the cornerstone of my permission granter app ^^’

The ACL for the specific folder is:

@prefix : <#>.
@prefix n0: <http://www.w3.org/ns/auth/acl#>.
@prefix per: <./>.
@prefix c: </profile/card#>.

:ControlReadWrite
    a n0:Authorization;
    n0:accessTo per:;
    n0:agent c:me, <mailto:my@email>;
    n0:default per:;
    n0:mode n0:Control, n0:Read, n0:Write;
    n0:origin <https://divoplade.frama.io>.
:Read a n0:Authorization; n0:accessTo per:; n0:default per:; n0:mode n0:Read.

My public profile https://divoplade.fr/profile/card#me has:

:me
    n1:trustedApp
            [
                n1:mode n1:Append, n1:Read, n1:Write;
                n1:origin <https://divoplade.frama.io>
            ].

[jeffz]

As I understand it, to do anything at all with an ACL, both the webId and the app must have Control over the resource the the ACL refers to. In your code, only the webId has this.

[divoplade]

I have [ a n0:Authorization; n0:origin <https://divoplade.frama.io>; n0:mode n0:Control ] in the parent container’s ACL; is it not enough?

[jeffz]

No it is not enough. ACL files only refer to webId access. To grant the app access, you must do so in the trustedApp section of your profile.

[divoplade]

Oh, so I guess I misunderstood the purpose of the A button in the pod’s Sharing widget. What is it for?

At Web Access Control (WAC) | web-access-control-spec I read:

A specific ACL can be made to allow a given app to access a given file or folder of files, using `acl:origin` .

[jeffz]

OK, if that quote from the spec has been implemented, your setup still does not accomplish it. The ACL of a parent Container is only checked if there is not a more specific ACL for a resource: The inheritance rules for ACL state as the first rule of inheritance

Use the document’s own ACL resource if it exists (in which case, stop here).

So if granting app permission at the resource level is supported, it needs to be done in the specific ACL for that resource, not its parent.

[divoplade]

In my case, the inheritance applies because there is no ACL for the resource itself yet. I will make a small app to expose the problem.

[divoplade]

https://divoplade.frama.io/solid-control-problem/

So, the fine-grained permission works for acl:Write but not acl:Control.

[jeffz]

You should file an issue on NSS about this. AFAIK, there is no support in NSS for setting app permissions in an ACL file, regardless of what the spec says. It would be good to clarify if this is true or whether your problem is caused by a bug. Please report back if you find out.

[divoplade]

I would love to do so, but unfortunately every time I try to sign up at Github I get a “Your account has been flag” as soon as I verify my email (I tried different emails), so I guess it would not work…

[jeffz]

I’ve asked in the chat room and will follow up with an issue if I don’t get an answer there.

[divoplade]

Update: in fact, it works but only if the origin is not present as a trustedApp on the profile! This is due to https://github.com/solid/acl-check/blob/master/src/acl-check.js line 191: if the app has been globally trusted, all fine-grained permissions are discarded. I don’t understand why it is needed, but the obvious workaround is to remove the offending triples from the public profile.

[divoplade]

Note that the trustedApp relation should stay in place, because otherwise the user is prompted to authorize the app next login and they come back. Instead, all modes should be removed, leaving an empty authorization:

:me
    a schem:Person, n0:Person;
    n1:trustedApp [ n1:origin <https://your.app> ].

[divoplade]

I am tackling the issue under a slightly different angle now:

https://sam.divoplade.fr/v

I am writing the code at:

https://sam.divoplade.fr/src