deprecate wac:Control

[bblfish]

In todays authorization panel (see PR) it was pointed out that the access modes were currently defined in the spec.

So @matthieubosquet argued and others seemed to agree that

It is the purpose of the Solid protocol to define which operations can be performed depending on granted access modes.

Given that I would like to point to the issue #94 deprecate acl:Control, replace with ... that I mistakenly wrote up in the WAC spec site thinking that this issue was decided there.

[bblfish]

pretty cool that this issue is numbered 303!

[kjetilk]

My initial reaction is that it is an interesting idea, but then "how far do we recurse?" I.e. is it only the first ACL resource that has an ACL resource, or can that go on?

[bblfish]

but then "how far do we recurse?" I.e. is it only the first ACL resource that has an ACL resource, or can that go on?

Most servers that move away from acl:Control, would be set up so that
the Access Control Resource links to itself.

Let me illustrate with a simple example to make things clear. Say
a client makes a request on /some/document

GET /some/document HTTP/1.0

and the server responds

401 Unauthorized
Link: </some/document.acl>; rel="acl"

That Link points to the ACR. Then a GET on </some/document.acl> would return

200 Ok
Link: <>; rel="acl"
Content-Length: 1022
Content-Type: text/turtle
.....

There is no new danger of infinite recursion that did not exist before: since web pages and RDF documents can already have links pointing to themselves. That is: any good web client, needs to keep track of the resources they have already visited to avoid re-visiting resources. Good caches and DBs are helpful for that.

[bblfish]

@kjetilk suggested leaving out acl:Control from the discussion on modes and moving it here. So I will summarise the new mathematical aspect that I introduced recently to the discussion here.

The discussion on Modes starts with a very nice inheritance diagram with three categories of modes, narrowing into various subcategories.

What is important here are the top three categories: Read, Write and Control. What my study of mathematics over the past 5 years has led me to discover is that of those three: Read and Write are fundamentally important in the mathematics of dynamic systems. And dynamic systems themselves are expressed as coalgebras that are duals to another fundamental concept in mathematics and computing namely algebras.

Dynamical systems (see recent book) are based on two types of functions on a state S.

1. a observation function get: S -> A
2. a change function put: S -> A -> S which from a state and a value returns a new state.

Note that in the 1990ies Bart Jacobs' Objects and Classes Coalgebraically found these to give a theory of Object Oriented Programming: the setters and getters of Java Beans were not an arbitrary invention! For a full history of the concept see Lenses for Philosophers.

Later Functional Programming rediscovered this as Lenses which are Monadic versions of the above. And recent mathematical work shows that these fall into a general conception of lenses which can model dynamical systems. For many more resources see this twitter thread.

So Read and Write is I am pretty sure set in stone. The two functions mentioned above can be used to model all the modes under Read and Write, and I wrote a very simple one page "Web Server" using Lenses to demonstrate that.

• Lens based Web Server
• Test Code
• on the topic of Web and Lenses see web-cats issue 28.

Control is something completely different. The fact that we can do without it as argued above and in WAC issue 94, gives a good indication of that.

To get a handle on control it is worth going back to the work of Abadi, Burrows and Needham around 1990 with A Calculus for Access Control in Distributed Systems where they present a logic of access control, where A controls p is a short for if A says p then p.

That is why I think it is actually better modelled as being the Link: <doc.acl>; rel="acl" header. Arguable that should be "controlledBy" . For our resource Guard follows exactly such a rule: whatever ACL rules are linked to in the Link header, is true. It is true for the guard, but it is the agency that matters.

[bblfish]

A little additional point. In N3 one would model the basic ABNL says relation as a relation between an agent and a context, using the N3 builtins.

@prefix log: <http://www.w3.org/2000/10/swap/log#> .
:says a rdf:Property;
    rdfs:domain foaf:Agent;
    rdfs:range log:Formula;

A formula is a generalisation of a graph (they can contain variables), and a graph is what an RDF resource returns. So we should be able to say things like,

:John :says </accessRules>

where </accessRules> contains

 []  :accessTo :WhiteHouse
      :mode Enter;
      :agent </me#> .

We can express that in Trig as a relation to a named graph, and in N3 as

:John :says {
 [] :accessTo :WhiteHouse
     :mode Enter;
     :agent </me#> .
}

What is in the { ... } is not to be taken to be true by any guard just like that, unless one believes what :John says.
This is an intensional context, which is related to modal logic. In Functional Programming the S4 modality is strongly
related to Monads. In 2008 Abadi showed that the says modality is an Indexed Strong Monad.
See the discussion I initiated on the N3 mailing list on Modal Logic last month. Also note how this ties in to early work by @dckc who was already pointing to Abadi Needham Burrows Logic in a note on A Model of Authority for the Web, where he ties this to speech acts too. And what are speech acts other than things that happen when one "says" something? It just remains to notice that publishing a document on the web is a form of saying.

So back to :controls . In ABNL we have

{ ?a :controls ?p } => { ?a says ?p . ?p a log:Truth } =>  ?p 

In WAC we have that a guard takes the HTTP header

Link: <?acl>; rel="http://www.w3.org/ns/auth/acl#accessControl"

returned by a resource R to be something akin to that. For the Guard, any AccessControl statement with respect to R found in ?acl is the truth on which the Guard will act and approve or deny access. Since the Guard determines access, what is written there becomes true. But all that needs to be specified is what types of Read or Write are allowed.