This note discusses usecases and requirements for Access Control for the Linked Data Platform WG. It also outlines a charter for developing a standard for HTTP-based access control. The work delineated in the charter may be pursued in the Linked Data Platform WG or an independent, related WG.

While the Linked Data Platform WG. did not address Access Control directly, a number of usescases and requirements were identified as part of its deliberations. These usecases and requirements are captured in this document to serve as a basis for future work.

Access Control

Access Control is a mechanism through which an agent ( an HTTP server in this case ) permits other agents -- individuals, organizations, and/or groups made up of these -- to perform certain operations on resources as specified by policies for the resources and for the agents . Within this document, the resources are LDP resources, but the access control may operate at different granularities: RDF or other documents, named graphs, individual triples, or individual attributes. The operations are create, read, update, and delete (CRUD).

When an agent requests a collection of resources it gets to see only those resources or parts of resources it is authorized for.

Depending on the granularity, the access control mechanisms may affect performance, but should not affect semantics.

For access control to come into play, the server must restrict some operations on some resources.

Terminology

Usecases

Access Control on manipulation of resources via HTTP

Adam's user agent attempts:
  1. To CREATE, READ, UPDATE (or PATCH), or DELETE a resource identified by a URL. The server may immediately allow or deny the request, or it may request that he authenticate to confirm his privileges, as specified the by the ACG for the Resource.
  2. To UPDATE, CREATE or DELETE an attribute of the resource identified by the URL. The server allows or denies the request as specified the by the ACG for the resource and attribute and whether fine-grained access control is supported.
  3. If he is denied access, an explanation of why all or part of his request was denied should be provided so that it becomes possible to detect errors, and so that he may modify the request -- potentially to include making a request for such privileges.
  4. Adam would ideally like to know whether he will be able to perform an Action on a Resource before attempting such - i.e., whether he will have to authenticate before he is able to Read or Write the Resource.

Editability of Access Control Rules using HTTP

  1. Bart's user agent logs on to a server and requests:
    1. The ability to read a group of related resources such as all the papers presented at a conference.
    2. The ability to update an attribute of related resources, for example, to add a copyright notice to each resource.
  2. Employees with job titles VP or SVP can sign (update) supplier contracts.
  3. Charlie, the Webmaster, would like to grant read access to the papers presented at a conference to all the people who attended the conference.

User Interface Scenarios

Eddie's HTTP based user agent would like to provide a user interface to allow, where possible, Eddie to
  1. Know if he can edit or delete a resource.
  2. Know what he would have to do to have access to a resource ( be someone's friend, be part of a club, have paid a fee )
  3. Allow Eddie to edit the access control rules for a resource such as:
    1. Allow friends of his to access a document.
    2. Allow friends of his to POST to a container, but only read a subset of the contents of the container, those posted by that agent for example.
    3. Allow all the members of the LDP WG to create and edit resources including LDP Containers under a specific URL pattern.
    4. Allow all friends of friends as expressed by the foaf:knows relations in one's foaf profile to POST comments to a container related to some content, and edit their own comments.
    5. Allow the members of the LDP WG, the RWW CG, the WebID CG, and the member of the European Ontologist Network, to work together on set of ontologies. It should be possible to drag and drop URLs for these groups, found on the web, onto the User Interface as a way of creating the union of the members of the group.

Requirements

      The above requirements require the ability, by an authorized agent, to CREATE, EDIT, UPDATE relevant ACGs.

Outline of a Charter for a Access Control WG

An Access Control Graph (ACG) consists of two kinds of collections: a collection of agents and a collection of resources. It then connects a collection of agents with a collection of resources with the connection identifying the privileges the agents have on the resources: CREATE, READ, UPDATE, DELETE.

ACGs are resources in their own right and can have access control priviledges specified for them just like any other resource. This permits the creation and modification of ACGs to be delegated.

The members of the collection of agents contain tokens that the agents obtain from some authentication service. The members of the collection of resources are URIs or URI templates.

The WG will need to decide whether it also wants to define fine-grained access control at an attribute level.

Deliverables

  • Define the collections that are part of the ACG and define how a collection of agents is connected to a connection of resources.
  • Define how ACGs can be created and edited and how these rights can be delegated.
  • Describe a proof-of-concept implementation of how a request for access to a resource by an agent can be processed efficiently with the ACG structure defined above.