authorization-panel
authorization-panel copied to clipboard
solid
Append-only access
https://solid.github.io/authorization-panel/wac-ucr/#basic-appendonly
Alice is interested in seeing whether any of her other contacts might provide good recommendations that she can include as additional references or a resume cover letter.
She creates a recommendations resource, and grants append access to the contacts authorization group, which represents every professional contact in her virtual rolodex. She sends a mass-mail to contacts, with a link to an app they can use to submit a recommendation, which will be appended to recommendations. Since they only have append access, and no read access, they can only add to that recommendations, they cannot see recommendations that have already been added.
This use case gives me impression of making a stretch to fit specific requirement suggested by its title - appending to a non container resource. If we would take this as real world scenario, it would seem more reasonable to me if it resulted in different set of requirements.
- each contact can read recommendation they have created
- each contact can edit recommendation they have created (even just to correct typo)
- Alice should have an audit trail to know which contact created which recommendation
I understand that current set of use cases intends to provide full coverage over current WAC documentation. At the same time I think we should avoid creating use cases which seem artificial.
I think an append only resource make sense for notifications.
Alice subscribes to a Container that lists events (using a yet to be defined method). The result of that subscription request being accepted, is that the container will post a notification to the resource whenever there is a change, avoiding alice to have to constantly poll the resource.
As I understand use case above intends to involve a non container / collection resource to which people append.
As I understand use case above intends to involve a non container / collection resource to which people append.
That was my understanding too. The container I mentioned above was part of the background story about notifications, not the resource to which appending was attempted. Perhaps I can clarify as follows:
- Alice subscribes to a Container C1 that lists events by passing in the URL of an append only resource R to which notifications should be sent (protocol to be developed probably). The result of that subscription request being accepted by C1 is that
- the container C1 (or rather the server hosting the container) will then post a notification to R whenever there is a change to C1, avoiding Alice's server to have to constantly poll the resource.
That is we have here server to server communication.
@elf-pavlik I think you make a good point about if you could design the initial use-case differently to where instead of a single 'shared' resource, each recommendation would be its own resource.
Another case I could imagine for append-only on a resource would be something like a log file. While you could certainly deconstruct that the same way to where each log entry is its own resource it would quickly spiral to an unmanageable number of resources.
