How to use the WAC-Allow header on auxiliary resources?

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