Unable to specify a policy where child resources can be accessed if there are permissions specified for the parent container.

[argahsuknesib]

With the implementation of the Privacy Preserved Stream Monitoring Service, stream events are written to a particular container. The container stores the stream events, which are then fetched with a GET request to do further stream reasoning.

To write a policy allowing the stream writer service to write stream events in a container the policy specified is,

ex:replayerPolicy a odrl:Agreement .
ex:replayerPolicy odrl:permission ex:replayerPermission .
ex:replayerPermission a odrl:Permission .
ex:replayerPermission odrl:action odrl:modify, odrl:read, odrl:create, odrl:append .
ex:replayerPermission odrl:target </pod/accelerometer-data/> .
ex:replayerPermission odrl:assignee <replayer#me> .
ex:replayerPermission odrl:assigner </pod/profile/card#me> .

Doing either POST or PUT requests will create resources which will be stored inside the /accelerometer-data/ container.

To read the stream events stored in these resources, with a GET request. Currently, a new policy check has to be done for each of the resources, even though the odrl:assignee has the right to read the parent container i.e. the /accelerometer-data/.

This creates extra policy check overheads, as well as uncertainty on how to specify the policies as then one has to write the policy for each of the files on the fly. Writing the policies can be cumbersome for each of the child resource created, as then the flow will be,

• Stream writer service writes to the pod with a POST request.
• Stream writer service updates the policies and appends the policy the exact child resource to be read by the service wishing to do a GET request (e.g. the monitoring service).
• The Authorization Service maintains a view to be updated with the latest policy being written.
• Monitoring Service does a GET request for the latest event, and the AS service evaluates the access for the exact child resource.

In a streaming scenario, with streams creating more than 4 events per second such flows can't be realized without adding additional latency which decreases the usability of the service.

Is there a way where one can specify the policy such that one can specify the policy on the container, and is allowed to read the child resources present inside the container as well?

Thanks!

[joachimvh]

This is mostly a discussion on how to map ODRL policies to the structure of Solid resources. Specifically how to model something similar to ACLs acl:default or ACPs acp:memberAccessControl. Using a new action for this seems cumbersome as you would then need twice the amount of actions. But on the other hand, using a refinement or constraint also seems wrong as I think those are supposed to reduce the scope of the action instead of expanding it.

[joachimvh]

As an inbetween solution, until this is resolved, I updated the derived resources component a bit so you could use this as a workaround that also solves your problem for now. I was going to create a new branch with the changes, but they are so minimal I'll just write them here.

Changes needed to make this work:

In packages/css/package.json update the @solidlab/derived-resources-component dependency to ^1.2.0
and create a new config, e.g., packages/css/config/derived-default/json and put the following in it:
Edit: see comments below

You probably also want a new script to start the server with that config. When starting the server with that config the RS will now also be able to have derived resources.

Then you need to add metadata to your RS to indicate where this derived resource should be. Let's assume your set of resources are in /resources/, and you want the derived resource at /foo/derived, you need to add the following to /foo/.meta:

@prefix derived: <urn:npm:solid:derived-resources:> .
<>
    derived:derivedResource [
        derived:template "derived";
        derived:selector <../resources/*>;
        derived:filter "latest"
    ].

After this, /foo/derived will always return the contents of the most recent document in the /resources/ container.

Let me know if something isn't clear or isn't working correctly.

[argahsuknesib]

Thanks for the support for the derived resources. I have a derived resource at /alice/derived/.
However, the www-authenticate doesn't refer to the UMA authorization server. I remember vaguely that in the previous version, the www-authenticate header had metadata to go to the authorization server. What do you think?

Header when trying to access /alice/derived/

Headers {
  [Symbol(map)]: [Object: null prototype] {
    vary: [ 'Accept,Authorization,Origin' ],
    'x-powered-by': [ 'Community Solid Server' ],
    'accept-ranges': [ 'bytes' ],
    'access-control-allow-origin': [ '*' ],
    'access-control-allow-credentials': [ 'true' ],
    'access-control-expose-headers': [
      'Accept-Patch,Accept-Post,Accept-Put,Allow,Content-Range,ETag,Last-Modified,Link,Location,Updates-Via,WAC-Allow,Www-Authenticate'
    ],
    'content-type': [ 'application/json' ],
    link: [
      '<http://n063-02b.wall2.ilabt.iminds.be:3000/alice/derived/.meta>; rel="describedby", <http://n063-02b.wall2.ilabt.iminds.be:3000/.notifications/StreamingHTTPChannel2023/b0>; rel="http://www.w3.org/ns/solid/terms#updatesViaStreamingHttp2023", <http://n063-02b.wall2.ilabt.iminds.be:3000/alice/derived/.acl>; rel="acl"'
    ],
    'www-authenticate': [ 'Bearer scope="openid webid"' ],
    date: [ 'Mon, 28 Apr 2025 11:15:11 GMT' ],
    connection: [ 'keep-alive' ],
    'keep-alive': [ 'timeout=5' ],
    'transfer-encoding': [ 'chunked' ]
  }
}

[joachimvh]

This is going to end up being a bit less simple as I hoped I just realized.

The config I linked above is wrong, it accidentally links to the original CSS config instead of the UMA-CSS one. But after changing I discovered there seems to be an issue with the internal caching of the derived component when seeding. Now that can be disabled and worked around, but then I just realized that UMA requires resources to be registered on the AS, which is something that currently does not happen with the derived resources, so I'll also have to look into that. So I'll get back to you when I got that working 😅.

[joachimvh]

Actually not that much changes required to get it working. Most of my previous comment is still correct except the example configuration. What you need to do is add "derived:config/derived.json" to the imports of your configuration, as well as the new context "https://linkedsoftwaredependencies.org/bundles/npm/@solidlab/derived-resources-component/^1.0.0/components/context.jsonld". You can either do that in your already existing config, or in a new one that imports the previous one like the above example (but then import the correct one 😅).

Besides that you also want to update the CSS dependency to ^7.1.7. I'm not sure why, but there were errors with the older version that is currently being used in the UMA repository.

The comment I made about registering the derived resource is currently not relevant, as it seems the UMA server doesn't actually look at what resources are registered. At some point in the future we will have to look into that but for now it's not needed yet.

[argahsuknesib]

Thanks for the help! I will modify it and update you here.

[argahsuknesib]

So I could get the CSS running by restarting the machine at VW. However, the derived resources still doesn't allow reading the child resources without explicit permissions there.

I have a derived resource at, http://n063-02b.wall2.ilabt.iminds.be:3000/alice/derived/
I wrote some stream events to it, such that I can see this following when doing an authorized GET to the derived resource.

@prefix dc: <http://purl.org/dc/terms/>.
@prefix ldp: <http://www.w3.org/ns/ldp#>.
@prefix posix: <http://www.w3.org/ns/posix/stat#>.
@prefix xsd: <http://www.w3.org/2001/XMLSchema#>.

<> a ldp:Container, ldp:BasicContainer, ldp:Resource;
    dc:modified "2025-05-05T08:21:53.000Z"^^xsd:dateTime.
<22be6655-9eb8-4dd4-bc16-ac53fb710832> a ldp:Resource, <http://www.w3.org/ns/iana/media-types/text/turtle#Resource>;
    dc:modified "2025-05-05T08:21:53.000Z"^^xsd:dateTime.
<069a58ae-8af9-4e83-8eac-a6ab854701d1> a ldp:Resource, <http://www.w3.org/ns/iana/media-types/text/turtle#Resource>;
    dc:modified "2025-05-05T08:21:42.000Z"^^xsd:dateTime.
<> posix:mtime 1746433313;
    ldp:contains <22be6655-9eb8-4dd4-bc16-ac53fb710832>, <069a58ae-8af9-4e83-8eac-a6ab854701d1>.
<22be6655-9eb8-4dd4-bc16-ac53fb710832> posix:mtime 1746433313;
    posix:size 81.
<069a58ae-8af9-4e83-8eac-a6ab854701d1> posix:mtime 1746433302;
    posix:size 9

Now I wish to access the child resources, such as 22be6655-9eb8-4dd4-bc16-ac53fb710832 by doing a GET request to http://n063-02b.wall2.ilabt.iminds.be:3000/alice/derived/22be6655-9eb8-4dd4-bc16-ac53fb710832 with the policy stating permissions for the derived resource.

I get a 403 status code when trying to access the resource.

[joachimvh]

The derived resource solution will not allow you to access the specific resources through policy, the idea is that you have a single resource that returns the results of whatever is the most recent resource.

The output that you put above is just the standard output of a container.

Assume all your sensor data is in resources in the container /pod/accelerometer-data/. Create a container such as /pod/derived/. In that container, edit the metadata at /pod/derived/.meta. Add the following triples to that metadata:

@prefix derived: <urn:npm:solid:derived-resources:> .
<>
    derived:derivedResource [
        derived:template "my-resource";
        derived:selector <../accelerometer-data/*>;
        derived:filter "latest"
    ].

If you now send a GET request to /pod/derived/my-resource it will return the contents of the most recent document from the accelerometer-data/ container.

[joachimvh]

Policies that are applicable to the contents of a container are now possible in the feat/collection-policies branch, which builds upon the branch that fixes #47 so both issues are handled in that same branch. The branch includes some explanation in docs/collections.md.

[joachimvh]

This is resolved in #50