acl:Authorization for multiple agents/targets

[tpluscode]

Related to #169

Is it valid to have multiple objects of acl:accessTo, acl:agent, acl:agentClass and other predicates?

The readme of solid/web-access-control-spec suggests only one for each of those but I don't see anything speaking against..

[acoburn]

An ACL can most certainly have multiple triples of these types.

Using multiple acl:agent triples is very common. Multiple acl:agentClass is less common, as foaf:Agent is (generally) the only value used with that predicate. Having multiple acl:accessTo predicates is more an implementation decision, specifically whether a given ACL resource can be used by multiple resources -- not in the inheritance sense but rather as the target of a rel=acl link header. Some implementations of WebAC support that (e.g. Fedora Commons); Solid generally doesn't given that the lifecycle of an ACL resource is generally bound to the resource it protects.

[tpluscode]

I'm looking at using WAC internally to control access to a Hydra API. I will certainly want to use the group feature for much more than just foaf:Agent.

And definitely would take advantage of multiple values for acl:accessTo(Class) as for example I so far defined as a generic rule to make an API accessible in general

prefix hydra: <http://www.w3.org/ns/hydra/core#>
prefix foaf: <http://xmlns.com/foaf/0.1/>
prefix acl: <http://www.w3.org/ns/auth/acl#>

<> a acl:Authorization ;
   acl:agentClass foaf:Agent ;
   acl:accessToClass hydra:Resource, hydra:Collection ;
   acl:mode acl:Read ;
.

[csarven]

Thanks for this issue and discussion. Closing this issue as consensus is deemed to be captured in WAC Editor's Draft: https://solid.github.io/web-access-control-spec/ . See #authorization-representation , #authorization-conformance . Please use https://github.com/solid/web-access-control-spec for future discussion.