Clarify discovery, reading, and writing auxiliary resources

[csarven]

This PR introduces minimal changes necessary to clarify discovery, reading and writing of ACL and Description resources (specifically under Auxiliary Resources) - to be consistent with the rest of the Protocol. Further re-organisation of content is left for future PRs.

The PR also address the key concerns raised in PRs #248 and #250 . If accepted and merged, then those two PRs should be closed immediately.

---

Access controls that are required to read-write ACL resources are specified by the WAC specification. The outer Protocol - in this case the Auxiliary Resources section - must take care to not introduce potential confusion or conflicts.

As it stands, access controls required to read-write Resource Descriptions are specified in the Auxiliary Resource section.

---

On the removal of line:

                 <p>To discover, read, create, or modify an ACL auxiliary resource, an <code>acl:agent</code> MUST have <code>acl:Control</code> privileges per the <a href="https://github.com/solid/web-access-control-spec#acl-inheritance-algorithm">ACL inheritance algorithm</a> on the resource directly associated with it.</p>

As per ACL Ontology: having Control access on a subject resource allows an agent to Read and Write the ACL resource that's associated with it. The text "read, create, or modify" is redundant and should be avoided.

---

WAC currently does not specify access controls needed for the discovery of an ACL resource via the subject resource it is associated with (ie. Link rel=acl). However, the discovery of a ACL resource associated with the subject resource is already described in the Auxiliary Resources section, and currently relies on Read rights:

Clients can discover auxiliary resources associated with a subject resource by making an HTTP HEAD or GET request on the target URL, and checking the HTTP Link header with the rel parameter [RFC8288].

It alludes to server including the Link header to allow a client to discover the ACL resource when agent has Read access on the subject resource.

Aside: It is still possible to specify the inclusion of the Link header also part of 4xx responses, but this is left for a future PR.

---

On the removal of line:

                 <p>A Solid server SHOULD sanity check ACL auxiliary resources upon creation or update to restrict invalid changes, such as by performing shape validation against authorization statements therein.</p>

The WAC spec will cover this in detail.

---

On modifying the lines for creating, modifying, discovering, reading description resources:

                 <p>To create or modify a description resource, an <code>acl:agent</code> MUST have <code>acl:Write</code> privileges per the <a href="https://github.com/solid/web-access-control-spec#acl-inheritance-algorithm">ACL inheritance algorithm</a> on the resource directly associated with it.</p>

                 <p>To discover or read a description resource, an <code>acl:agent</code> MUST have <code>acl:Read</code> privileges per the <a href="https://github.com/solid/web-access-control-spec#acl-inheritance-algorithm">ACL inheritance algorithm</a> on the resource directly associated with it.</p>

The change simply states that access privileges on description resources come from subject resource's.

For discovery, same reason as earlier when a client can observe the link relation targeting an auxiliary resource. At this time, the commonality is that Read is required on the subject resource for the purpose of discovery.

[acoburn]

LGTM. By removing unnecessary text here, this makes the protocol document more concise and consistent.

[bblfish]

As it omits the problematic text of #250 that is ok for me. I don't have a good enough overview of the whole document to comment on the value of such a large change over and above the smaller change proposed in 250.

[matthieubosquet]

LGTM

[matthieubosquet]

Could we simplify further?
"A subject resource's authorization MUST apply to its description resource."

[TallTed]

That implies that the resource's authorization is the thing taking action.

The imperative is on the server, to apply the same authorization as is on the resource to the description resource(s), and I think we've got just about the simplest, clearest possible wording.

[dmitrizagidulin]

👍
this is a good clarification.

[RubenVerborgh]

Good improvement, avoids repetition.

[michielbdejong]

LGTM, thanks for looking into this so thoroughly Sarven!

I closed #248 in favour of this one.