Specify container listing mechanism

[csarven]

• Should container descriptions omit statements about its resources from agents that are not privileged to read (acl:Read) the resource? ( See also Current Container Listing mechanism does not support hidden resource use case #626 )
• Should container descriptions omit statements about acl and meta resources? ( See also Handling requests without an interaction model #105 )
  • Should it be possible to reveal them when requested (eg. Prefer include=...all analogous to ls -a)?
• ..

[ericprud]

Concrete example:

http://alice.pod/share/photoAnnotations/

<http://alice.pod/share/photoAnnotations/> a ldp:BasicContainer ;
  ldp:contains <annot123>,  <annot456> .

# data cached from contained resources
<annot123> a photo:Annotation ;
  dc:author "Alice" ;
   photo:photo <http://amy.pod/photos/photo123.jpg>, 
   photo:caption "Alice and Amy at work" .

<annot456> a photo:Annotation ;
  dc:author "Alice" ;
   photo:photo <http://bob.pod/photos/photo456.jpg>, 
   photo:caption "Bob sleeping at work" .

Timeline:

1. Alice created the container
2. Alice allowed Bob to "contribute" (append and own his contributions)
3. Alice creates annot123 and annot456
   -- unprivileged GET on /share/photoAnnotations/ gets a everything in the container
4. Bob asks Alice to restrict access to the "Bob sleeping at work" photo.
5. Alice sets ACLs on annot456 to only allow Alice and Bob to see it.
   -- unprivileged GET on /share/photoAnnotations/ ideall doesn't get either the link to or the triples

<annot456> a photo:Annotation ;
  dc:author "Alice" ;
   photo:photo <http://bob.pod/photos/photo456.jpg>, 
   photo:caption "Bob sleeping at work" .

[csarven]

• Should container descriptions omit statements about its resources from agents that are not privileged to read (acl:Read) the resource? ( See also Current Container Listing mechanism does not support hidden resource use case #626 )

In the context of access controls, there are generally two cases to consider pertaining to the binding relationship between a LDP resource and the container it is in:

1. Unless otherwise specified, an agent with Read access to a container can observe its containment triples ie. read the names of the resources it contains. Access to each resource in the container is subject to the permissions of the resource itself - this is orthogonal, and may be obvious but important to emphasise. This is a common behaviour in *nix systems and compatible with chmod and setfacl in that if the permission block applicable to the user has +r, then they can see the directory's contents (filenames) regardless of the setting on each of the files. Similarly, well-known Web servers eg. Apache, would include all files as long as the directory index is enabled/allowed.

2. In order to have a strong privacy protection pertaining to containment, restricting the visibility of resources in containment triples is required. That is, an agent without Read access to a resource in a container should not be aware of its existence through containment triples - so as to not leak or expose information. This makes it possible to have a public read container meanwhile having the ability to effectively have a fine-controlled containment listing.

Aside:
I want to note here that one way to organise containers and resources would be to simply restrict read access on the container so that its resource names are not exposed through containment triples. Another way around this would be to not add resources to a container so that they don't show up in containment triples. However, this is not possible given consensus in #98 (comment) about containment being strictly hierarchical. There may be exceptions but I'll leave that investigation for another discussion/issue.

---

AFAIK, when we discussed WAC/ACL, we've generally used chmod as analogous to ACL modes. It is close enough for some cases but not accurate enough. setfacl is in fact much closer to how we've been using WAC/ACL. However, I would argue that that itself is insufficient with respect to what we've been trying to get out of WebACL (at least in a declarative way). We need to clarify the extent of using expressive policy rules in junction with ACLs so that the "out of band" expectations is actually part of the rules we want to set. Using *nix like systems as analogous, this may be along the lines of SELinux, AppArmour, and alike - so, possibly moving in the direction of or borrowing from Mandatory Access Control (MAC).

To that end, and FWIW, I've created solid/authorization-panel#55 and solid/data-interoperability-panel#31 to properly explore the ODRL Information Model (but it could also be something else) and to see how it can work with WAC/ACL. What this may entail is having default (pod) policies to express a layer of rules and conditions when interacting with resources.

For container listing, I propose that we adopt a privacy first approach as a default. That is, agent with Read access to container can view all containment triples with the exception of contained resources that they do not have Read access to.

Going forward, as soon as we can express that declaratively eg. how ACL+ODRL works in close proximity to LDP, we can specify the behaviour (as MUST?) but still allow other possible pod configurations (as MAY?) eg. an agent's Read access or lack of is not part of the policy in constructing containment triples.

[simonstey]

something along the lines of ->

<http://alice.pod/share/policy>
    a odrl:Policy ;
    odrl:conflict odrl:perm ;
    odrl:prohibition [ 
        odrl:target <http://alice.pod/share/photoAnnotations/> ;
        odrl:action odrl:use 
    ] ;
    odrl:permission [ 
        odrl:target <http://bob.pod/photos/photo456.jpg> ;
        odrl:action acl:Read;
        odrl:assignee :Alice, :Bob 
    ] .

?

[kjetilk]

@timbl explained to me in a F2F discussion that he considered putting details like in the above examples to be a bad practice, you shouldn't do that. Instead, he had suggested using a different resource for that purpose. The databrowser uses index.ttl throughout for this resource.

The way that I now understand it is that should not be interpreted as a default resource for the container (#69), it is not a representation of the container, merely an easily accessible aggregate of certain data from the contained resources. He suggested that even though he had some regrets about calling it index.ttl, this practice should be continued. I think a case could be made that such a resource should be referenced with a special predicate, I think saying <./> rdfs:seeAlso <./index.ttl> . in the container would be a good idea when it exists.

Merely moving these data to a different resource doesn't resolve all concerns in this resource, as access controls are more granular for resources in a container than for the container itself, which I understand motivates the desire to list only resources that a client is authorized to read. This is a general departure from the current Solid, though, as the ACL system currently has a resource as the smallest unit. It is also a departure from the UNIX filesystem analogy. This suggests to me that a best practice recommendation is to not put things in the identifier someone with read access to the container shouldn't see.

Other than that, I think we should stay close to the UNIX filesystem analogy, i.e., the container has containment triples, required metadata, optional timestamps, etc, but not actual user data.