Removing support for acl:accessToClass?

[awoods]

The Solid spec does not support acl:accessToClass as a design decision. We currently do and acl:accessToClass is part of the original specification. Does Solid become our base and we remove support for acl:accessToClass?

Extracted from: #145

[dannylamb]

If we consider SOLID to be our base, then I feel we're bound to remove it.

[zimeon]

I agree. What is the impact on existing users of removing current support?

[awoods]

The use of accessToClass has proven to be a very effective way of creating Authorization policies that apply to resources of specific classes. Dropping this would be a reduction in capability.

[zimeon]

Discussion on editors' call yesterday was that we don't know of implementations using acl:accessToClass in F4, even though it looks like a nice capability

[zimeon]

Raised on 2017-07-27 Fedora Tech Call - nobody present expressed concern about removing or said they use acl:accessToClass in F4.

[peichman-umd]

We (UMD) are interested in it for the purpose of simplifying our ACL structure, but we have not implemented it in any of our ACLs yet.

[jwestgard]

To add on to what @peichman-umd said, we had/have a vision for maintaining a few access control policies as resources in Fedora, and having assets point to those policies rather than minting an ACL for each asset. As with so many things, however, the devil is in the details. With the current Modeshape implementation's limitations around objects with many members and the WebAC implementation's security-driven requirement that assets point to ACLs and ACLs point back to objects (in order to close the loop and thereby to prevent any user with write permission on an object also being able to change its access policy) -- we currently have a hard time seeing how it will ever be practicable to implement our original vision for repository-managed access controls.

All that having been said, currently it would not present a problem for us if the feature were to be removed.

[zimeon]

@jwestgard -- this issue is just about binding inherited policies via a resource's semantic (RDF) type. With WAC inheritance and/or explicit association of many resources with a single ACL I think your use-case could be supported by the current WAC proposal, and would not use acl:accessToClass anyway.

[jwestgard]

Thanks, @zimeon. I agree this removal wouldn't present a problem for us. The main blockers to implementation of our original vision are the lack of a configuarable access-control membership predicate and the many members issue. Sorry if I muddied the waters with the earlier spiel.

[escowles]

Based on discussion in the 8/16: we should add a normative block saying:

• implementations MAY support acl:accessToClass, despite SOLID saying not to
• if an implementation does not support acl:accessToClass, it MUST reject the creation/update of any ACLs with acl:accessToClass, with a Link header with rel=constrainedBy pointing to a document saying acl:accessToClass is not supported

[escowles]

@acoburn FWIW, the resolved-need-pr label means that the editors have discussed it and agreed on an approach — not that no one else does or might object to the PR.

I certainly don't expect implementations to support inferencing for resolving acl:accessToClass, and would be happy to include language that says this explicitly and details some of the scenarios you have outlined.

I also think that the use case that's been discussed in mailing list messages should probably be documented. But briefly the use case is:

• A repository with a large number of resources (500k newspaper objects, for example) that should be managed by a single ACL.
• Some implementations (Modeshape) will be unable to manage an ACL that links to 500k resources.
• Any implementation that can manage that will be unwieldy (managing a resource with 500k triples is a burden)
• Duplicating the ACL is undesirable, since the objects are managed as a group and any ACL change should be applied to all of the resources.

This is functionality that is working in the Modeshape impl , and being used right now. Absent an alternative proposal to address this use case, we'll move forward with allowing implementations to support acl:accessToClass.

[jwestgard]

Containment was our original plan for this, but currently Fedora WAC implementation does not support setting different membership predicates (other than ldp:contains) for inheritance purposes, or at least that is my understanding. We don't want to insert semantics into the arrangement of resources in our repository by relying on ldp:contains here (i.e. our repository has a flat structure).

Just to be clear, we have not yet implemented this because our current content is able to be made public and so we use a single ACL at the repository root that allows public read of everything. We will very soon have assets that we need to restrict, and we are looking at any options that would allow us to avoid setting an ACL for each resource (which AFAIK is the current Samvera approach).

[escowles]

@jwestgard The spec continues to insist that only ldp:contains be used for walking up the hierarchy to find the appropriate ACL to use, so I think the new implementations will continue to have this issue of requiring you to put all of your resources that want to share an ACL into a single container. So I think acl:accessToClass is a reasonable way to do that.

This is really a tangent, but I have been in favor of keeping semantics out of URIs, in large part because the repository path and the URIs of the resources being described must be the same in Fedora 4. I think other implementations will allow you to describe other resources, so http://example.org/private/resource1 could include triples about http://example.org/resource1. With the ability to do that, we might be able to use LDP containers to manage resource access.

[jwestgard]

@escowles We agree that keeping access semantics out of URIs is a good idea. Cool URIs don't change, but access restrictions do over time. The worst case scenario is that we'll end up with an ACL for each resource, but we want to explore every alternative before we go there.

[barmintor]

Another option for the @jwestgard use case might be to use the root (or defaultForNew) to describe the read-only resource, and create a restricted container to put the more specialized policy in place there - presuming the flat URIs are a retroactive concern?

[jwestgard]

Thanks, @barmintor for this. We are in fact using the root/default policy for publicly readable resources. We considered grouping resources under either collection containers or access-policy containers to accommodate more restricted resources, but in both cases we are worried that we'd be attaching semantics to the location of the resource in a way that could bite us later. In the former case we have items that are in multiple collections and in the latter we envision restrictions changing over time.

[zimeon]

Discussion on 2017-09-14 API Spec meeting suggestion that we should add wording:

• implementations MUST support acl:accessToClass
• explain what acl:accessToClass does
• inference is a MAY

[zimeon]

where I think that the second bullet in above means:

• ACL documents may contain authorization conditions of the form #auth1 acl:accessToClass A_class
• which means that the authorization #auth1 applies if the resource (for which this is the ACL) is of rdf:type A_class OR matches any other acl:accessToClass or acl:accessTo condition in the authorization
• and the check on rdf:type A_class applies to both server managed and explicit type statements (so binaries would match #auth1 acl:accessToClass ldp:NonRDFSource)