search

solid / notifications

Solid Notifications Technical Reports
https://solid.github.io/notifications/protocol
MIT License
11 stars 7 forks source link

Changing access policy for a topic resource may require invalidating some channels #185

Open elf-pavlik opened 11 months ago

elf-pavlik commented 11 months ago

Currently, we only assume that access will be checked when the notification channel gets created. We don't seem to address a common scenario when access policy changes on the resource which is a topic of some existing notification channels.

I think every change to access policies, would result in re-evaluating all the channels using that resource as their topic. If the receiver doesn't have required access anymore, their channel should be most likely deactivated.

Related issues:

CxRes commented 11 months ago

I am putting these concerns out there with the intention of discussion than immediate resolution.

Would you invalidate the channel, or would you modify it? For single topic channels, invalidation is the way to go, but for multi topic channels either could be justified.

Also, should we include this in SNP (we do not specify how security is implemented) or does this need to go into its own document (or even just an implementation note) where we tell servers to be aware of this consideration?

joachimvh commented 11 months ago

This was also one of my considerations in https://github.com/solid/notifications/issues/114.

This would add additional issues for server implementation though, as every time an authorization resource is updated, the server needs to a) find all resources impacted by this change b) find all notification channels for those resources, and c) determine the impact of the authorization changes on all those channels.

In the case of a container ACL changing, this would mean recursively finding all child resources without an ACL. With ACP it would just be all child resources as there container permissions are not always overwritten by document permissions. And then for all those resources check the new permissions for the WebID that subscribed to that specific channel.

This is all known information to the server so can be done, but that could potentially trigger a lot of actions on the server by doing a single operation on an authorization resource, as a lot of resources might have to be loaded to do all those checks.