Auxiliary Resources with own Access Controls

[csarven]

https://solidproject.org/ED/protocol#auxiliary-resources does not specify access controls on auxiliary resources themselves.

Raising this as an issue as it its essence was brought up by different people over time, e.g.:

• https://github.com/solid/specification/issues/63#issuecomment-944919914 to be able to allow a Description Resource to be readable where the resource it is associated with (subject resource) may be protected.
• https://github.com/solid/specification/issues/184#issuecomment-671030265 summarises some cases for readable ACLs, and it is an age old consideration, e.g.: https://github.com/search?q=org%3Asolid+%22readable+ACL%22&type=issues
• https://github.com/solid/specification/issues/355#issuecomment-1439884108 raises intended access controls on storage description resource.
• ...

Related issues:

• https://github.com/solid/specification/issues/184
• ...

Notes:

• Decoupling the authorization rules of auxiliary resources and subject resources would require a change in requirement: https://solidproject.org/ED/protocol#server-description-resource-authorization would be a conformance change as per https://www.w3.org/2021/Process-20211102/#class-3 .

[matthieubosquet]

Maybe worth linking to those related authorization issues as well:

• https://github.com/solid/authorization-panel/issues/189
• https://github.com/solid/authorization-panel/issues/150
• https://github.com/solid/authorization-panel/issues/210

From the perspective of the ACP domain model, the approach and solution to such concerns could be quite generic because any resource can have an access control resource. The following, for example, is perfectly valid:

ex:resource1 acp:accessControlResource ex:acr1 .
ex:auxiliaryresource1 acp:accessControlResource ex:acr2 .

Generally, given that:

1. Auxiliary resources' lifecycle should depend on the primary
2. Eventually something needs to express access over itself (r1 --rel:acl--> acl1 --rel:acl--> acl2 ... acl83729 ... doesn't practically work)

I don't think there is a lot of interest in implementing a system where auxiliary resources link to their own rel=acl resource.

I think I would be in favour of:

1. Allowing the acl of Solid resources to express specific rules for auxiliaries
2. Defaulting to auxiliary permissions being applicable for auxiliaries

Allowing the acl of Solid resources to express specific rules for auxiliaries

This is already the case for ACL that express access to themselves via the acl:Control mode. It would be possible to devise a new mode for specific types of auxiliaries... but that would be quite inconvenient because it would require new modes for each new type of auxiliary resource.

I think it would be preferable to express access to auxiliaries resources via their relation to the primary. In other words, I would rather express control over the thing that describes the primary resource rather than control over the description auxiliary resource itself. For example, ammending my first ACP example in that optic:

ex:resource1 acp:accessControlResource ex:acr1 .

[]
  rel:describes ex:resource1 ;
  acp:accessControlResource ex:acr2 .