WebAccessControl

WebAccessControl is a decentralized system for allowing different users and groups various forms of access to resources where users and groups are identified by HTTP URIs.

Index

The system is similar to the access control system used within many file systems except that the documents controlled, the users and the groups are all identified by URIs.
Users are identified by WebIDs. Groups or users are identified by the URI of a class of users which if you look it up returns a list of those in the class. This means a person hosted by any site can be a member of a group hosted by any other site.

You can give access to a document on one site to users and groups hosted by other sites. Users do not need to have a profile on the site to have access to documents on it.

In order to be able share common code a common ontology is proposed which provides the terms necessary for access control lists to be stored.

Vocabulary

See also the discussion page about the WAC vocabulary (incl. a schema visualization).

If you look it up with Tabulator (or equivalent) you should get the definitive
information. It will not be completely repeated in this wiki.

Note that there are properties of an Authorization which allow you to specify who gets access either by giving a relation to a specific user or a different relation to a class of user. The same technique is used for expressing to which resource or class of resources access is being granted.

There is a relationship between a resource and its access control list resource.
This is to allow a user agent to allow user interaction with the ACL, for example by an ACL editor.

Agents and classes

An Authorization is an abstract thing whose properties are defined in an Access Control List.
The ACL does NOT have to explicitly state that it is of rdf:type Authorization.

agent

agentClass

Public Access

Servers are required to recognize the class foaf:Agent as the class of all agents.
This indicates that the given access is public.
In some cases this will mean that authentication is therefore not required,
and may be skipped.
When a resource is being written, however, it may be necessary to associate the change with some kind of ID for accountability purposes.

@@ TBD: The class of agents with WebIDs would be a useful addition, which would require authentication but place no further constraints on the agent.

Any number of agents and/or agentClasses may be specified in an ACL file.

accessTo

accessToClass

Modes of Access

In the ontology modes are classes -- think of them of classes of operation. The Read mode is class operation which includes all those operations which reveal information about the content of the resource.

Mode:

Those allow may:

Read

read the contents (including querying it, etc)

Write

overwrite the contents (including deleting it, or modifying part of it).

Because acl:agent has domain foaf:Agent the last line implies that <card#i> is a foaf:Agent.

Protocol

The user authenticates to the server using FOAF+SSL, either failing or returning a WebID.

The server looks in it local ACL information for the resource, according to the local convention. (e.g for access to/foo/bar.baz, in /foo/.meta/bar.baz.meta). This is parsed (as typically N3) into RDF graph G.

If the WebID is mentioned explicitly in the file as being allowed access then access is granted.

If not, if there are classes of agent which would be granted access, then for each class C the class URI is checked in a cache, and if necessary looked up on the web, returning a document parsed to a graph Gc. If Gc contains { ?WebID rdf:type ?C } the the user is granted access.

Note that the protocol is very strict about where information comes from: the user's WebID profile is only checked for being cross-linked withe the certificate during the FOAF+SSL process, but is not believed for any information on class membership and so on.

The server reads the ACL file. When a request comes in it checks whether the ACL file information is sufficient
for allowing access as is, and as it is not, it looks up the group files.
If it were very well optimized, if a write request came in, it would only look up the family file, as that is the only one which could give write access.

Modifying Access Control information

The design goal is that the WebAccessControl storage should be a creative medium in which

new WAC'd information resources can be set up by the user

new WAC'd information resources can be be set up by an distributed client-side application on behalf of a user,

without the intervention of administrative humans running the storage server.

The server of the resource in question gives a link acl:acl from the resource to the URI of an associated ACL resource.

<profile> acl:acl <.meta/profile.meta>.

or say

<profile> acl:acl <profile,meta>.

(Note that the system must make up some URI which suits itself. It may on a file-system-based service
correspond to a file, in which case the URI may simply map to a file name.
However it can also be any form of storage and the URI can be made up so that it will connect to
the access control list system. Note that there are some advantages in having the two URIs close in the tree so that
relative URIs can be used in the link and in the ACL information itself.)

(This link may be given in profile itself or via the HTTP link header which is used to link to associated metadata.
A common agreed form must be used -- if in the future site metadata files and standard ways of defining them are defined then these would be an alternative.)

The client follows, for example, an HTTP header field:

Link: <meta/profile.meta>; rel=meta

and in meta/profile.meta it finds amongst other things

<../profile> acl:acl <>.

i.e. "This is the ACL for profile".

The server indicates that the user can edit the ACL in the normal way for editable linked data.
The client puts up an optional window, panel, etc, containing ACL editing user interface.
The changes are written back in the normal way for editable linked data.
SPARQL/Update is the preferred method as it allows small changes to be sent but WebDav will work.

rel=acl or rel=meta?

Neither the acl nor the meta link relations have been registered as required by RFC5988 on Web Linking in the IANA link relations registry. Both probably should be registered. The meta relation suggests that the document linked to could contain any metadata about the resource. For pictures metadata could be information such as who appears in the picture, when the picture was taken, etc... Acl relations are going to be very important for the infrastructure of the web, so it would be very helpful if the data in the linked to document was very precisely about
access control.

Just to help gather consensus, please add which of these your implementation uses, with pointers to the code or service.

Sanitation of the request

In prototype systems one can use a generic SPARQL/Update system to control the ACL resource.
However when write access is given to parties who are not totally trusted then the system MUST check that
the ACL modification request does contain only valid ACL information.

Extension

It is reasonable in the future to allow different forms of information to be stored in the same writable
metadata space as the ACL. There are a class new protocols which so not require any functionality in the
server side. These include the storage of information about licensing, appropriate use, provenance of the original resource. It is not clear whether these are better implemented by extending the WAC metadata or by a system
built on top of the WAC's storage layer, using a separte WAC's resource for the new metadata.
The decision is in general a little analogous to the decision on a Mac OS file system.