ACL creation and linking -- be explicitly silent or specify?

[zimeon]

The SOLIDWEBAC specification and the Fedora specification are both currently silent on how or when and ACL may be created and linked to the resource(s) it is designed to control access for. The following cases all seem conforming at present:

• An implementation aiming to provide easy migration from Fedora4 WebAC might require an additional type to indicate an ACL (currently an ACL is a BasicContainer with a specific type, which has children for Authorizations -- this has to change to single resource) and use the acl:accessControl property on a resource to indicate its ACL (this predicate is in the WAC ontology but is not mentioned in the SOLIDWEWAC spec)
• An implementation has a default ACL that applies to all resources and it never creates nor allows creation or linking of any other ACL (assumes Reconcile WAC and the possibility of uncontained resources in Fedora #163)
• One default ACL as previous bullet that can be edited to be the sole source of fine grained authorization data for many resources (sounds like scaling nightmare!)
• An implementation automagically creates a new ACL for every resource created (based on some implementation policy, which might (but need not) be based on the idea of inheritance at creation) and thus avoids the need for any inheritance when later determining which ACL applies
• An implementation allows creation of ACL documents by creation of an LDPRS that smells like an ACL (I say this because ACLs are not typed), and is linked to a resource based on interpretation of the acl:accessTo (has rules determining whether linking happens for one or more resources, what to do if one of these already has an ACL, etc.)
• An implementation allows linking an LDPRS to a resource as its ACL by some other means outside of Fedora and LDP specs
• ... more I'm sure ...

IMO, we should either be explicitly silent:

Non-normative note: Behaviors regarding the creation of ACLs and associating them with the resources they control access for are not defined by [SOLIDWEBAC] or this specification.

or specify some restrictions.

(I believe that, given the understanding that an ACL is an LDPRS, and the acl:Control permission (#170), changes to an ACL can be made with PUT/PATCH as normal under LDP.)

[escowles]

I think it would be nice to at least specify one or more options for creating ACLs that should be supported. Otherwise, any client wishing to create resources with ACLs will have to have special knowledge of the implementation's choices in that regard.

[birkland]

I like how the LDP spec deals with descriptions for LDP-NRs via describedby, and an analogous treatment for acl could be easy to understand without being overly burdensome; i.e a server MAY create an ACL for any resource; if it does create an ACL, then it MUST expose it via a Link <...>; rel=acl. Clients can then discover it, modify it, etc.

I think several (most?) implementations of web acl do that.

[awoods]

I would suggest it is a requirement that one ACL could be applied to many resources distributed throughout the repository, to address both the scaling concern as well as to reduce duplication of policies.

Is there concern about specifying the current approach?

An implementation aiming to provide easy migration from Fedora4 WebAC might require an additional type to indicate an ACL (currently an ACL is a BasicContainer with a specific type, which has children for Authorizations -- this has to change to single resource) and use the acl:accessControl property on a resource to indicate its ACL (this predicate is in the WAC ontology but is not mentioned in the SOLIDWEWAC spec)

[escowles]

As I've said before, I think it would be good to specify one way that clients can declare what ACL should be used for newly-created resources. There was some discussion of this at the last editor's meeting, and it would look something like:

• A client creating a resource may include a Link rel="acl" header pointing to an existing LDP-RS to use as an ACL.
• The server must respond with a 4xx if it isn't able to use that LDP-RS (not sure if this should be 400 or 409 or something else).

[escowles]

@acoburn I don't think we should exclude other implementation patterns, including having a server-managed ACL link like you're describing for Trellis, or the Modeshape impl's pattern of including a triple pointing to the ACL.

But all things being equal, I think it would be good to specify one pattern for clients to specify their ACLs, because otherwise implementations that support that will naturally vary.

[whikloj]

Can I just ask a question, I was responding to this thread and I realized that the Solid Spec does not use the acl:accessControl property either.

I'm having (pragmatic) concerns/thoughts. Does that mean you check all ACLs to find any all that have an acl:accessTo for the resource you are requesting?

[whikloj]

@acoburn that' s interesting. So the server will place the ACL in an expected location for each resource.

Would that not mean that the acl:accessTo becomes much more restricted in what it could refer to? Because if you have two trees (B & C) from root (A), then while an ACL on a resource in tree B (which would be in an expected location for that resource) could refer to a resource in tree C.

However there is no way that the resource in tree C would know it was covered by that ACL.

I guess you could parse the ACLs (on insert/update) to validate that they are only referring to the expected resources.

I'm not particularly tied to acl:accessControl but I'm just seeing that removing it and acl:accessToClass (both of which have issues) causes you to move to add more ACLs to your repo to cover your resources.

Unless (and this is a viable option) I've misread the spec and so missed the substance of the discussion.

[whikloj]

@acoburn ok, I realize that the concerns I have are more of a server-side or implementation concern. The clients should be blissfully unaware, but I was just wondering what the general thoughts around this were. thanks.