Authorising giving read access to others but not modifying

[fabienpe]

I would like to do the following:

• Alice has the full control of a file on a pod.
• Alice wants to allow Bert
  • to read (but not modify) the file and also
  • to be able to allow Christopher to read the file.

Here is what I've done but I keep getting an unauthorised error.

• Create a readers.ttl file which Bert can modify and contrains a group where he adds Christopher
• Add to file.acl read access to the group defined in readers.ttl

file.acl:

@prefix acl: <http://www.w3.org/ns/auth/acl#>.
@prefix foaf: <http://xmlns.com/foaf/0.1/>.
@prefix readers: <readers.ttl#>

<#public>
    a acl:Authorization;
    acl:accessTo <./file>;
    acl:agentClass foaf:Agent;
    acl:mode acl:Read.

<#owner>
    a acl:Authorization;
    acl:accessTo <./file>;
    acl:agent <https://XXX/Alice/profile/card#me>;
    acl:mode acl:Read, acl:Write, acl:Control.

<#Bert>
    a acl:Authorization;
    acl:accessTo <./file>;
    acl:agent <https://XXX/Bert/profile/card#me>;
    acl:mode acl:Read.

<#readers>
    a acl:Authorization;
    acl:accessTo <./file>;
    acl:agent readers:group;
    acl:mode acl:Read.

readers.ttl

@prefix : <#>.
@prefix vcard: <http://www.w3.org/2006/vcard/ns#>.
@prefix m1: <https://XXXX/Christopher/profile/card#me>.

:group
    a vcard:Group;
    vcard:hasMember m1:.

Should this not work? I don't understand why it does not. Any idea?

[joachimvh]

The triple should be <#readers> acl:agentGroup readers:group (not acl:agent), but even then it is not going to work. I'll reference my comment in #1442 (comment), but the core is that a target of an acl:agentGroup needs to be a publicly accessible resource since the server needs to be able to access it.

[fabienpe]

Am I correct to then understand that the second option discussed on this blog
https://www.konsolidate.eu/stories/solid-and-authentic-sources
is actually not possible?

[joachimvh]

Actually I was mistaken now that I think about it. It should still be possible as you can give public read access to readers.ttl but only allow Bert to modify the document. So it depends on what the ACL for readers.ttl looks like.

Another potential issue is that in v5 there is a cache for accessing group resources which defaults to an hour. So any changes made to the document would not be seen immediately which might also be cause of your issue. The v6 branch removes this. Or you can modify your configuration by setting the cache timeout to 0 seconds by adding the following to your configuration:

{
  "@id": "urn:solid-server:default:AgentGroupAccessChecker",
  "@type": "AgentGroupAccessChecker",
  "expiration": 0
}

[fabienpe]

Thanks. I had the public read on the ACL for the readers.ttl. It was indeed the timeout which messed things up. So it does work, but... there is a small privacy issue that anyone can see the list of agents allowed to read the data.

[rosshorne]

Related to this thread @joachimvh
I'm wondering whether there are problems in this kind of scenario when a .acr file is created instead of an .acl file. That is, we wish to, from an app/agent combo with acl:Control privileges on a resource set the ACP policy for the given resource.

A colleague has been trying to do this and reports the following:

"When I try to save as a .acr file, I receive an error that access is forbidden, and this only happens for this specific file extension whereas .txt for example is fine."

Thanks.

[joachimvh]

The permissions for accessing a resource that defines permissions, either a .acr for ACP or a .acl for WAC, are different from those of standard permissions. To do anything with such a resource you need acl:Control permissions instead of acl:Write.

I'm not sure how similar your scenario is, but note that ACP does not have the concept of groups like WAC does.

[elf-pavlik]

This is a comment about the future of authorization in Solid rather than how to do something with CSS currently.

Alice wants to allow Bert

• to be able to allow Christopher to read the file.

This should be handled as delegation, one of the approaches I have initially captured in

• Support longer delegation chains solid/data-interoperability-panel#222

We are also looking at alternative approaches, such as Bert issuing a VC/VP to Christopher, later Christopher delegates to their client, and the Client pushes all needed claims to Alice's UMA authorization server.

I'm just mentioning that because without proper delegation mechanisms in place, trying to satisfy your use case will have various issues, like privacy, when using WAC group-based permissions.

[rosshorne]

Hi @elf-pavlik I like the idea of delegation chains. It reminds me of Henry’s work and also nested VPs, as you suggest.

Maybe it's my bad for adding to an existing query rather than starting a fresh one, but we're looking at something simpler:

Suppose an owner is granted acl:Control access to a whole pod. How can an app that they log into (and implicitly trust with acl:Control) set a new policy. I'd expected the app to simply write the policy to an .acr file. If an app the owner is logged into cannot write to .acr, then what can and how, given that we can't expect most pod owners to be able to program from the backend? (We may simply have gone wrong with our usage of the typescript or something, but I expected this to be a core use case)

[elf-pavlik]

Hi @rosshorne, it does sound like a distinct issue; maybe you can create a dedicated issue or discussion with more details to reproduce it?