Difference between revisions of "WebAccessControl"

From W3C Wiki
Jump to: navigation, search
(rel=acl or rel=meta?)
Line 199: Line 199:
Implementations using <b>rel="acl"</b> to point to acls
Implementations using <b>rel="acl"</b> to point to acls
* [https://github.com/stample/rww-play rww-play]
* [https://github.com/stample/rww-play rww-play]
* [https://rww.io/ rww.io]
=== Sanitation of the request ===
=== Sanitation of the request ===

Revision as of 12:12, 1 September 2013


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.


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.


The ontology is http://www.w3.org/ns/auth/acl

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.


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.


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).
Append add information to [the end of] it but not remove information.
Control set the Access Control List for this themselves.


@prefix acl: <http://www.w3.org/ns/auth/acl#> .
@prefix foaf: <http://xmlns.com/foaf/0.1/> .

[acl:accessTo <card>; acl:mode acl:Read; acl:agentClass foaf:Agent].
[acl:accessTo <card>; acl:mode acl:Read, acl:Write;  acl:agent <card#i>].

This means that anyone may read card, and <card#i> can write it. ( we won't put the prefixes in any more from here on )

[acl:accessTo <card>; acl:mode acl:Read; acl:agentClass foaf:Agent].
[acl:accessTo <card>; acl:mode acl:Write;  acl:agent <card#i>].

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


  1. The user authenticates to the server using FOAF+SSL, either failing or returning a WebID.
  2. 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.
  3. If the WebID is mentioned explicitly in the file as being allowed access then access is granted.
  4. 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 access control list is:

[acl:accessTo <card>; acl:mode acl:Read; acl:agentClass <http://my.example.net/groups/friends#group>].
[acl:accessTo <card>; acl:mode acl:Read, acl:Write;  acl:agentClass <groups/family#group>].

This means that anyone in the group <http://my.example.net/groups/friends#group> may read card, and <groups/family#group> can write it.

The resource <http://my.example.netgroups/friends> says:

<#group> is rdf:type of  </user/alice>, </user/bob>, </user/charlie>. 

The resource <groups/family> says:

<#group> is rdf:type of  <../people/don>, <../people/eloise>. 

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.

See also how meta was used at W3C in the early days

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.

Implementations using rel="meta" to point to acls

Implementations using rel="acl" to point to acls

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.


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.


The following systems implement or plan to implement WAC:

Are interested

Broken links

  • WACup, a WAC explorer/viewer for RDFa implemented with jQuery and rdfquery (client-side)


Mailing List