Auxiliary resource for container metadata as alternative

[kjetilk]

Given @acoburn 's objections in https://github.com/solid/specification/pull/352/files#r764244049 and onwards, I decided to write down an alternative to #352 that introduces an auxiliary resource (hereafter known colloquially as a stat resource), as proposed by @acoburn , myself and others. We can hold these two PRs up against each other.

I believe this PR solves the following problems:

• It ensures that the entire resource is taken into consideration when computing last modified, and thus avoids the staleness problem of #352.
• Since the data goes into an auxiliary resource, the container itself is not modified when a child is modified, and thus avoids the cascade-to-root problem.
• I allow the aux resource to have its own access control, which should alleviate the concern that metadata may be exploited to find vulnerabilities somewhat, as it can be used to restrict access to these data further than the container permissions indicate.

The drawbacks of this approach is, AFAICS only that NSS would have to be modified slightly and thus clients currently using these data would need to GET another resource. I believe this is a small cost that should be taken as soon as possible, but it is also possible that this proposal should be considered for 1.0 and not 0.9.

I have in the present proposal required that this stat resource exists, and I have registered opposition to that. I believe that having this aux resource would make a fine implementation detail too, you'd record any changes on the aux resource on the backend, and so it should ease implementation too. If it is still insisted that this should be optional if it is too expensive, then I suggest that we make the discovery sentence a SHOULD, as if there is no discovery, there's no stat resource.

I think that further work on this should include making data for representations explicit, things like size and media type shouldn't be on the resource, but on the representations.

[kjetilk]

Thank you very much @acoburn . I am happy to change the name. I wasn't sure what to call it, but decided to include "server" to allude to that it is server managed, but that is also made clear in the text, so I am happy to change it.

[kjetilk]

The Solid Editors meeting decided to merge #352 today, but indicate that the mechanism may change, so we may return to something like this later.