A high confidentiality scenario that one should not forget

[bblfish]

This high confidentiality scenario partly explains some aspects of LDP Containers.

[dmitrizagidulin]

Why hashing and not just a random uuid?

[bblfish]

I just meant the path names to be opaque. Perhaps using UUIDs generators are a good idea. It is just that the path names don't need to be globally unique.

[elf-pavlik]

I agree that hashing may only bring unintended confusion. UUID seems like a safer alternative for this use case.

[bblfish]

I also agree that the concept of a hash brings with it the question "hash of what?", where an default answer tends to be "of the content, of course", which is not the intention at all. A UUID on the other hand stands for a Univerally Unique Identifier, which is too strong for the use case. Is there a word that captures something in between?
Looking for "Locally Unique Identifiers" I found quite a few questions concerning those on Stack Exchange and even a longer blog post from 2010.

[elf-pavlik]

https://www.w3.org/TR/capability-urls/#capability-url-design

Good unique URLs include an unguessable unique identifier such as a UUID.

---

Even though we don't talk about capability urls, i think this suggestion for unguessable unique identifiers applies here as well.

[justinwb]

👍 to UUID

[elf-pavlik]

I agree that hashing may only bring unintended confusion. UUID seems like a safer alternative for this use case.

[bblfish]

@csarven brought up a concern during today's teleconf regarding how the issue about opaque filenames had been addressed in Solid before. Note: this use case makes clear we need both.

The way to get both is to notice that LDP Containers are actually designed with opaque names in mind. There was no consensus there to specify Containers that would guarantee to a client that the created resource would occur within the </container/> namespace as </container/newname>.

But this is easy to remedy. I proposed creating iContainers where i stood for intuitive just for that purpose. If Solid wants the additional user friendliness @csarven said had become the consensus, then it should consider introducing iContainers. These allow clients to be able to POST documents with relative URLs containing <../> type paths. See my Issue 50 of LDP.

[justinwb]

I'm wondering if this is really an authorization use case, vs. a use case about how resources are or can be addressed/represented on the resource server itself?

[bblfish]

@justinwb it's a security/confidentiality use case. Some publishers don't want information leakage from URLs. Authorization is one aspect of security, and it affects authorization, as it means one has to build the protocol to make follow your nose discovery of ACLs explicit.

[bblfish]

I have updated the use case with an example container layout structure based on UUIDs.

[csarven]

To me this scenario is fundamentality about URI owners wanting to organise resources hierarchically in a way that is not coupled with assigned URI ie. information about hierarchical containment is in the resource description, and hence a matter of knowledge organisation. As said, the algorithm(s) to generate the identifier while important, the primary intention is to not expose any information about its contents or relation to other resources through its assigned URI.

I suggest that we should acknowledge the scenario because it is significant, but unclear as to where exactly it should be taken up - which layer(s) eg. resource access, knowledge organisation, access controls?

---

Some considerations below for when this UC is followed-up. If anything can be generally clarified in the UC based on the following, that'd be great.

The existing requirements in Solid may already or come close to covering the requirements that can come out of this scenario:

If servers are to assign a URI when creating a resource (as opposed to client's preferred), then POST to root container is the only way. Clients will have to specify their intention to create a confidential URI - perhaps through a Link header rel=type - and server has to guarantee it. Unless some exceptions are introduced to existing requirements on hierarchical containment, all confidential URIs are potentially discoverable through root container's description.

It also seems to entail that clients will have to manage containment statements. As to if and how the ACL inheritance algorithm can be applied here is unclear. Perhaps this scenario should be addressed more generally under resource access and knowledge organisation.

[bblfish]

I suggest that we should acknowledge the scenario because it is significant, but unclear as to where exactly it should be taken up - which layer(s) eg. resource access, knowledge organisation, access controls?

Thanks @csarven .

Currently it is in the Privacy section, which makes sense I think. The reason why it is relevant to authorization is that the scenario reminds us that we need to be explicit about how access control rules are followed and default reasoning is done. So it forces the follow your nose principle to be taken seriously (It's a good way to test that client or server libraries implement those correctly).

How such containers are created is out of scope for the authorization-panel. That would be something to be done on a different panel along with how one should create root containers.

Unless some exceptions are introduced to existing requirements on hierarchical containment, all confidential URIs are potentially discoverable through root container's description.

For hierarchical containment to work as you wish requires an addition to the LDP ontology as argued in issue 94: Enable full use of relative URLs in Solid. The default behavior of ldp:BasicContainers allows the behavior described here. I.e. this is a possible way an ldp:BasicContainer can work, as specified by LDP.

I do not think this creates a problem that all resources would be discoverable by a GET on the root container ( https://ciadotgov4sjwlzihbbgxnqg3xiyrg7so2r2o3lt5wz5ypk4sxyjstad.onion/ in the example) since not all resources are actually directly in the root container. They just seem to be from the URL perspective. But in the example given anyone who has read access to the root container would actually only see two ldp:contains entries. There we see again the importance of the follow your nose principle.

[justinwb]

Action Item - JB to update title and merge