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 Authoritative Contained Resource Data #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.

[acoburn]

Thank you @kjetilk, this is great.

My only suggestion (which is definitely in the bikeshedding category, so feel free to ignore) is to call this a Container Metadata Resource. To me, a Server Metadata Resource describes the server as a whole, rather than being server-managed metadata about a particular container.

[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.

[TallTed]

Suggested change

	An auxiliary resource of type <em>Container Metadata Resource</em> provides server-maintained metadata about contained resources.
	An auxiliary resource of type <em>Container Metadata Resource</em> provides server-maintained metadata about contained resources.

Shouldn't the type be a URI (presumably #auxiliary-resources-stat-resource with a base I'm not quickly seeing), rather than a literal?

[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.