[Use of copyrighted material without permission or consent]

[RubenVerborgh]

No description provided.

[csarven]

However, it does not specify what should happen for auxiliary resources, in particular for ACL resources.

Auxiliary resources are ... resources.

Should auxiliary resources have a WAC-Allow header?

I'd say that the MUST text for resource applies for auxiliary resources as well. That was intended but we can consider why it shouldn't be.

If yes, should the returned values reflect access control on the resource or the auxiliary resource?

However it is defined for a given an auxiliary resource. For the description resource (target of describedby), it would be the same as the subject resource (the described resource). For ACL resources, it'd would be the same as the ACL resource.

In the case of ACL, should we list Control, or all permissions?

List the permissions the agent/client is allowed. That'd be accurate and simplest I think. If you are checking about whether Control alone is sufficient, I believe it is. It doesn't need to be extended to include RWA.

[csarven]

Good issue.

Shall we list that explicitly in the spec though?

I agree, it'd be worthwhile.

Thinking:
If Control is allowed on resource, then ACL resource's WAC-Allow should include user="read write control" public="". But I can also see it working with just "control". If in the future only "read" or "read write" are used ({for reasons}), that can mean that the ACL resource can be modified but the ACL resource can't be controlled (e.g., having its own ACL). See below:

Some broader considerations while we work this out:

• Meaningful/Extensible if ACLs of ACLs are specified.
• Possible deprecation of Control.
• WAC-Allow's access-mode parameter to allow any term web-access-control-spec#82 (and also mentions if we can keep wac-allow in the protocol instead of wac for wide usage, that'd be great).

[csarven]

Reopening the issue as it was closed by a non-CG member at the time, without CG's consent. The last useful revision in #313 (comment) is below, before the comment was erased.

---

The current spec text says that

Servers exposing client’s access privileges on a resource URL MUST advertise by including the WAC-Allow HTTP header in the response of HTTP HEAD and GET requests.

However, it does not specify what should happen for auxiliary resources, in particular for ACL resources.

• Should auxiliary resources have a WAC-Allow header?
• If yes, should the returned values reflect access control on the resource or the auxiliary resource?
• In the case of ACL, should we list Control, or all permissions?

[csarven]

GitHub's ToS allow users to reference and reuse publicly available comments within GitHub (see Section D.5). And, the Solid GitHub org operates under an MIT license, promoting open collaboration and transparency. Additionally, as part of the Solid CG, contributions fall under the W3C Community Group CLA, which permits broad reuse within the community.