Clarify what are recommendations of Solid Web ACL

[whikloj]

In looking at writing the delta for Web AC in Fedora I am having some difficulties understanding what is meant by section 5

To configure access control restrictions, implementations must follow the recommendations of SOLIDWEBAC with the following additional requirements:

There are a variety of both design and implementation details in the Solid spec, but I'm not sure what we want to follow. Some of my specific questions are around:

1. acl:defaultForNew - we currently use an assumed inheritance is the Fedora spec requiring a change to this other pattern? (Honestly I'm not sure this is required by their spec either).

2. In the section Describing Agents the Solid spec presents the use of hash-uris for authorization documents. This seems like an implementation decision, but (and I can't believe I'm saying this) in the language of the document it isn't clear to me.

3. 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?

[awoods]

@whikloj : I agree, we need to be much more specific than simply saying, "Do SolidWebAC".

[zimeon]

Regarding 2 - I think the WAC spec uses hash URIs for blocks of authorization content within a document that has a non-hash URI. I think that to interpret an ACL document one must look for hash URIs that match <#something> a acl:Authorization; and then look at each <#something> authorization to understand what permissions it coveys and whether it should be inherited (if marked acl:defaultForNew ). As far as I can see the WAC spec nowhere explains this <#something> stuff -- seems like a bug in the WAC spec (and a bit ugly using implied fragment semantics in this way too).

[whikloj]

@zimeon I agree with your interpretation of the use of hash URIs in an Authorization.

Currently we do it with child resources (ie. a <http://fedora.info/definitions/v4/webac#Acl> resource with one or more <http://www.w3.org/ns/auth/acl#Authorization> resources ldp:contained inside it), so it is very similar in design.

Consequently I'm not opposed to using hash uris, but at this point I'm unclear if this would be a requirement or just an idea for future work.

[awoods]

@whikloj : I believe the examples in the Solid spec where Authorizations are represented as hash-URIs is simply an example, not a requirement.
We should clearly specify how Authorizations can be discovered given an ACL.

[whikloj]

@awoods, are you suggesting that this be laid out in the specification?

I'm thinking that if we are taking the Solid spec as more of a guideline, then perhaps we can be silent on the organization of the ACL/Authorizations resources. Especially because we created the ACL resource, it is not part of the WebAC spec (IIRC).

So perhaps as long as the over arching rules are complied with (ie. rules follow ldp:containment, etc). Then how the ACL/Authorization resources are organized is not important to the clients of a "Fedora".

However, things like the acl:defaultForNew are important as we don't currently acknowledge this at all in the Modeshape reference impl.

[awoods]

@whikloj : My concern is that we need to provide enough guidance so that clients can create ACLs/Authorizations that can be found and enforced by the given WebAC implementation... but I can also see that as an implementation decision.

Are you comfortable closing this issue as being subsumed by the three new, more granular issues:

• Requiring acl:defaultForNew? #164
• Removing support for acl:accessToClass? #165
• Algorithm for finding authorizations in an ACL document? solid/web-access-control-spec#19

[whikloj]

@awoods yeah I think I'm good with closing this in the context of the more granular issues you've opened.

I think that the guidance around how to create ACL/Authorization resource(s) should come from the WebAC spec (or in our case the Solid WebAC spec), which I think will be informed by the answer to @zimeon's question solid/web-access-control-spec#19.