Restrict linking and creation of extended auxiliary resources

[csarven]

There is a gap in the spec that would allow auxiliary resources to have their own Resource Description or Web Access Control auxiliary resources. Neither the lifecycle or the access controls on the extended auxiliary resources are prescribed. Until there are significant use cases for open-ended linking of auxiliary resources, and in order to restrict server implementations to be in a situation without conformance criteria to go with, we need to prescribe (something along these lines):

Servers MUST NOT use a link relation to advertise a Resource Description or Web Access Control auxiliary resource for auxiliary resources.

Shape auxiliary resources are necessary for Resource Description and Web Access Control auxiliary resources. Unless there is a significant use case for Shape Validation auxiliary resources to have their own Shape Validation auxiliary resources, I'd also suggest:

Servers MUST NOT use a link relation to advertise a Shape Validation auxiliary resource for other Shape Validation auxiliary resources.

[DaemonAlchemist]

From an app developers perspective, I agree that it would seem confusing if auxiliary resources had their own auxiliary resources or WAC files separate from the resource they describe. However, there is one use case a bit related to this that I haven't seen addressed in the spec.

As a user, let's say I have a photograph. I want to give it a title and tag some people in it. The title can be publicly accessible, but I only want people in my friend group to see who is tagged in it. Normlly, all of that info could go into the auxiliary description resource, but with the different access controls, it seems like we'd need multiple auxiliary description resources each with their own WAC resources.

The only solution I've been able to come up with so far is to link the auxiliary description resource to further custom description resources with sameAs links in the decsription metadata. However, that seems a bit ad-hoc.

[csarven]

WAC's authorization policy grants access privileges to information resources, as opposed to attribute based access control (or any particular graph or shape within the resource). So, it is not possible to have the title and tags described in the same description resource with different access controls.

sameAs (or possibly seeAlso) can work to set different access privileges, however, we haven't defined how those resources can be created and deleted, or any level of expectation that clients should follow the links. This falls on data interop.

The possibility of multiple description resources with different authorization policies can address the use case you mentioned, however there's currently two criteria that prevents that:

A given Solid resource MUST NOT be directly associated with more than one Descriptive auxiliary resource.

See also issue #173 considering to uplift this restriction.

To discover or read a Descriptive auxiliary resource, an acl:agent MUST have acl:Read privileges per the ACL inheritance algorithm on the resource directly associated with it.

That would mean that description resources need to have their own ACLs, hence decoupled from the resource that's associated with it.

[bblfish]

I think there are good use cases for having ACLs having their own ACLs (and I implemented a server following that). It starts with the need for ACLs to be readable by apps because Apps otherwise would need to try out every one of their Credentials in order to authenticate. See solid/authorization-panel#95 It is also related to the fundamental principle that clients and servers need both to know what the access rules are for these to work solid/authorization-panel#73

Given that, and since ACLs may be readable by more than can edit them, and since they are editable, they of course also require access control rules. Of course to avoid an infinite regress one just needs ACL to be their own acls. But that just requires an Link: <>, rel="acl" header.