@bblfish wrote:
ACL resources are resources like any other and are themselves access controlled. Making the access control relations explicit via a Link header is very helpful if only to allow clients to be able to help read and edit these resources consistently.
The simplest (and current behavior of SoLiD) is to put the access control rule for the acl in the acl file itself. But how should a client know that this information will be used by the server as an acl rule? After all a user can place acl triples in the body of a normal non acl resource and this won’t be acted upon by the server. A client furthermore may have no idea that it is looking at an acl file itself as it may have reached that file by following some non-acl-link from another document (potentially on another server). The usual answer is to put information controlled by the server in the HTTP header.
So the current behavior of SoLiD can be encoded using the Link header Link: <>; rel=“acl” . As an example the following acl states that the resource </document.acl> can be read and written to by agent <card#me>:
GET /document.acl
…
200 Ok
Link: <>; rel=“acl”
Content-Type: text/turtle
…
[] acl:accessTo <>;
acl:mode acl:Write, acl:Read;
acl:agent <card#me> .
What about the case when information about who can edit the acl file needs to be protected whilst the acl file itself needs to be public, or simply more widely readable? Two options present themselves:
the acl could point to yet another resource, with different access control rules with a header such as Link: <document.acl.acl>; rel=“acl”. Clearly there are pragmatic limits to how far such an acl of acl system should go, and so this MUST end with a resource that points to itself as its own acl.
The acl resource could be its own acl, but place the acl rules about who can edit it, in an acl:includeed resource that is itself protected.
Another use case may be the need to have a special admin user that can edit all resources on a site,
as required by issue 7: Implement a privileged “admin” user on Solid servers
This can be made explicit by a server pointing every acl point to itself, and to the admin acl .
Link: <>; rel=“acl”
Link: https://rww.io/admin.acl; rel=“acl”
This would allow the admin to use some administrative SoLiD based Application that would always give the admin rights whatever the self referring acl said, and without being editable by that user as would be the case in point 2 above.
It is most likely that most SoLiD system written initially will need only self referring acls. But keeping the door open for more complicated cases, and programming clients to work correctly with those, will allow these systems to work in more complex situations such as buisnesses, high security environments, etc…
As a side effect this patterns may also simplify the ontology by making the acl:Control type redundant. see issue 51: do we need acl:Control?.
In issue 51: do we need acl:Control @sandhawke wrote
The problem I see with ACLs on ACL resources is the end-user mental model.
Actually it is quite simple: “every resource has an ACL (even if it is its own ACL)” .
Anyone who understand the current WAC already understands this. The only thing is that it is not stated explicitly that the acl files are currently their own acl files. That this is the case implicity though can be shown as follows: by making a change in an acl resource. E.g. by changing say <document.acl> from
[] acl:accessTo ;
acl:mode acl:Control;
acl:agent <card#me>
to
[] acl:accessTo ;
acl:mode acl:Control;
acl:agent timbl .
one has actually changed the rights to the <document.acl>, and not necessarily those to . So the acl is its own acl: with wac:Control it is just expressing it in a pretty round about manner.
Also, will the spec say the acl for an acl is always itself, or is the server free to put it somewhere else? If it’s always itself the code can be pretty simple, yes.
There are use case for having every resource have an one or more ACL headers described in issue #61.
I think the code to implement this should be quite easy: Every resource is treated the same way. On a request to the server for an action such GET on a resource the Guard
Does a HEAD on the resource to find its acl header, if none is there it does not give access.
If there is one or more rel=“acl” Link it does a request on each of those resources, and finds out if it or its wac:inlcuded resources give the right access on the initially requested resource.
So if the request is for an acl, eg <document.acl> which declares itself to be its own acl, then 1 above will return the resource itself, and the server that has access to the resource will be able to get the document itself and continue with 2.
The client who may be using the same code may not be able to move to 2 if it is not granted access by the server to read that resource. But well in that case it already knows it does not have access. What it cannot know is what identity it could use to gain access.
The closer the guard is to the resource itself, the less leakage of acl info there will be across the server memory.
I am happy to say that at least the dev branch of rww-play actually works like this, and has since November 2013 commit 2198c642a4c214df8b19716f46a082085197f38d:
$ curl -i -k -H “Accept: text/turtle” https://joe.example:8443/2013/card.acl
HTTP/1.1 200 OK
Accept-Patch: application/sparql-update
Access-Control-Allow-Credentials: true
Access-Control-Allow-Headers: Authorization,Host,User,Signature-Date,*
Access-Control-Allow-Origin: *
Allow: OPTIONS, GET, HEAD, SEARCH, PUT, DELETE, PUT, PATCH
Content-Type: text/turtle
ETag: “1454695031000|Success(1404)”
Last-Modified: Fri, 05 Feb 2016 17:57:11 GMT
Link: http://www.w3.org/ns/ldp#Resource; rel=type, <card.acl>; rel=acl
Set-Cookie: PLAY_SESSION=c8a803396ccf3915fce4febee889d906947f66cb-subject=; Path=/; HTTPOnly
Content-Length: 538
…
One advantage of having ACLs for ACLs is that one could make ACLs protected to the owner, and thereby allow descriptions of authorised users with username/password combination. See the short gitter discussion on 2 Nov 2016 .
Another interesting use would be that for RDF Sources the resource could contain its own ACL. So an LDPR created by POSTing RDF to an LDPC could be its own ACL, which would reduce the need for the client to download one more resource.
There has been some discussion on https://github.com/solid/solid/issues/61 with @dmitrizagidulin and would like to invite more here.