Read-append access to a Collection

[elf-pavlik]

https://solid.github.io/authorization-panel/wac-ucr/#collection-readappend

Alice worked with Bob in the past on a project, and she has included the project deliverables she could find in the project1 collection. She’s sure that she’s missing some, and that Bob would have the missing items.

Alice grants Bob read access and append access to the project1 collection, which allows him to see the list of what is there, and add new resources to it.

He can’t see the contents of the resources, or remove anything in the list. That’s fine because he only needs to add the resources that aren’t included.

---

This use case seems to rely on Bob's capacity to process IRIs. Since Bob can't see contents of the resource, he is expected to recognize each resource just by section of IRI denoting it.

I would consider solid to be well designed if it provides full UX even when all IRIs are created based on something like UUID. In that case expecting Bob to recognize something just based on UUID used to create IRI identifying this resource sounds rather unrealistic.

Even worst, if Bob's client uses POST to append resource, and server uses UUID to generate IRIs for those new resources, Bob would need to make sure he keeps track of what he have already added since he wouldn't be able any more to recognize those resources (unless he also keeps track of Location HTTP Header in response to each POST).

[bblfish]

@elf-pavlik I think bringing in UUIDs confuses your point a bit since thare are URIs with no associated protocol and whose usage therefore is quite unclear.

You could make the same point by mentioning that LDP should work with resource names being opaque (clearly something that high security sites would need). Since the use case hints that the resources have just been created Bob would not be able to know that those URLs correspond to previous ones he worked with.

It is possible of course for LDP Containers to add metadata for ldp:contains resources to each resource (eg creation date, author, perhaps even some content description). I am not sure if that has been clearly specified yet.

But the use case does need to make that clearer if that is the idea.

There is a simple use case for appending to a collection and being able to read created document:

• a shopping cart
• a notification
• LDP based mail

Use cases for being able to see that contents exist but not being able to read them are going to be tricky to come up with. Perhaps a container containing votes, with metadata indicating who voted, a signed hash on the content that can later be verified? The whole container could then be made public (or visible only to the group) once everyone has voted, so that people can see that others are participating, but that their choice is not influenced by how others have voted.

[elf-pavlik]

There is a simple use case for appending to a collection and being able to read created document

To my understanding this use case only allows reading container (listing members) but not allows reading any resource / document contained in it.

a shopping cart

I would consider this use case requiring full read-write access to each line item customer adds to it.

[bblfish]

Yes @elf-pavlik that was also my understanding of the use case. That is why I suggested the use case be replace with something along the lines of

Perhaps a container containing votes, with metadata indicating who voted, a signed hash on the content that can later be verified? The whole container could then be made public (or visible only to the group) once everyone has voted, so that people can see that others are participating, but that their choice is not influenced by how others have voted.

That does not quite explain why the person posting the vote can't see what they posted though. Perhaps the idea is to stop someone who voted in a specific way being able to show someone else how they voted and so get paid for their vote (the hash might be problematic then).