OldAccessControlPage

---

This page has been superseded. Please go to Access Control for the WG's latest thinking on Access Control.

---

This page collects content for a future Note on Use Cases and Requirements for Access Control to be produced by the Linked Data Platform WG. The LDP Charter states:

The Working Group will not produce a Recommendation specifying solutions for access control and authentication for Linked Data. However the Working Group may identify, based on a set of real world use cases, requirements for authentication and authorization technologies for use with Linked Data.

Deliverable, Not Recommendation Track: Access Control: Working Group Note on Use Cases and Requirements for access control and authentication mechanisms needed for this work.

1 How to Contribute

Contributors, please include a brief description and example. Ideally, this page will provide a little orientation and analysis of the resources in Chris Bizer's Semantic Web Trust and Security Resource Guide ( no longer updated )

2 Access Control

Access Control is a mechanism through which permissions are granted (or denied) to entities -- individuals, organizations, and/or groups made up of these -- to perform operations on resources. Within this document, the resources are LDP resources, but the access control may operate at different granularities: RDF or other documents, named graphs, or individual triples. The operations are create, read, update, and delete (CRUD).

Entities and Resources need to be identified. See section on Identity below.

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

3 Use Cases

Please define here some access control use cases

3.1 Granting Groups (Write) Access to Containers

When working with Linked Data, one may need to grant write access on resources to members of some group of entities, such as the ability to POST their preferred meeting time for an event to a container.

Such a group could be identified by an LDPR such as the foaf:Group of people who attended the TPAC webid/rww/social-web meetup. The group could be also specified more generally, perhaps as "group members and their direct colleagues". This means that access to the resource can be granted very flexibly by delegating responsibility of permitted-group membership to each member. Editing group membership could then itself be done with LDP.

3.2 Giving access to open-ended sets of resources

It should be possible to efficiently specify that large sets of resources (existing or not) are (or will be) accessible to given entities (e.g., by using POWDER to specify regular expressions on resources).

3.3 Setting Access Control Policies for a Resource or set of resources

It should be easy to use LDP to set access control policies for a resource or collection of resources (e.g., an LDPC). For example, one could imagine a server that uses an LDPC to create user accounts. Anybody on the internet - or some permitted subset perhaps - could POST to that Container, and as a result have created a new LDPC of type sioc:Account. That user should then be able to set the access control rules for the LDPC they created and indeed for individual LDPRs therein.

3.4 Discovery of Resource Access Control Policy

Some agent A attempts to access a resource (a simple HTTP GET is sufficient), but is not allowed access. In some cases, such as high security systems, nothing more should be said. In most everyday scenarios, however, it is important to present the agent A with some reasonable explanation for why they did not get access. A link from the requested resource to the access control policy (ACP) would be very helpful. Perhaps A can find out that the particular resource is only visible to friends of some of the resource owner's friends - in which case the requester would know that by becoming friends with someone he could get access to the resource. Another resource may be accessible by members of a group, the members list of which can only be seen by existing members. That would at least allow members of the group to know if there was a bug in the server that denied them access. Without such information access control bugs would be more difficult to debug.

3.5 Clearer Error Reporting on Access Denial

Standardized precision of refusals would be very helpful in debugging systems and in making user interactions on access control systems more friendly. Perhaps a 401 or 403 should also include some machine readable information on what the error was, so that the client can distinguish clearly between different issues such as --

• Authentication problem
  • Could not verify one of user's principals (some type of identifier the user has)
  • Network problem in verification step
• Authorization problem
  • User is not authorized for a certain action
  • Network problem (e.g., could not access ACL)
  • Access error: server could not access the ACL to determine the authorization (perhaps due to ACL restrictions on the ACL itself)
  • Logic problem: Server does not understand the vocabulary of the ACL

3.6 Creating a new resource with ACL restrictions

A bug database exists for some product. A user wishes to create a new bug report on a security issue ( by POSTing it to a collection ) but wants to make sure it has limited visibility to give the software vendor time to fix it. The Bug reports are normally publicly readable. If paranoid enough it seems that doing this in two steps may be too slow: creating the resource and then later changing the access control rule. So there is a case that this needs to be done at resource creation time.

3.7 Identification, Authentication, and Authorization

Use of the Linked Data Platform often may require Authentication of Identity, and Authorization for the desired Access. Access by clients can depend on the interaction context (different resources are needed for accomplishing different goals), client identity (different clients have different levels of access), and possibly client roles (access control may be coupled to roles instead of specific identities, in which case client/role associations need to be established) and/or client attributes (access control may be coupled to some attributes which may be reliably knowable even when the client identities are not). On the Web, many different methods of identification (establishing naming schemes that uniquely identify entities of interest), authentication (frameworks for verifying someone's claim to have an identity), and authorization (granting access to a resource based on an identity and some access control scheme) exist. In addition, in many cases platforms must integrate into existing scenarios around these issues, and cannot freely pick a framework from scratch. Thus, LDP should provide developers with some guidance around the following issues:

• How should LDP services integrate into existing landscapes of identification, authentication, and authorization?
• What is a reasonable authentication model?
• What is a reasonable authorization model?

LDP will be used to drive many different services, and these might have different models of how clients should prove their identity, and how to check their permission to access LDP services, in the context of those specific application scenarios. What are reasonable models so that LDP providers can handle this flexibility, and still support the specific identification, authentication, and authorization frameworks that are dictated by the environment? In this context, is it more reasonable to deal with roles or attributes in granting (or denying) access to requesting clients? For some established technologies, maybe we can provide guidance and patterns on how to support them.

4 Requirements (based on Use Cases)

• Access Control Vocabularies
• Agent Identification
• Resource Identification
• ...

4.1 Summary by Use Case

This table summarizes the features of the technologies described below in the document.

	vocab	agent ID	resource ID
group access to collections	yes	???	???
access to open sets of resources		...	...
setting ACLs for resources		...	...
resource policy discover		...	...
[[#|]]		...	...
[[#|]]		...	...

4.2 Summary by Technology

This table summarizes the features of the technologies described below in the document.

	vocab	agent ID	resource ID
webacl	yes	???	???
Shi3ld		...	...
triple ACLs		...	...

5 Existing Technologies that Might Satisfy Requirements

5.1 Access Control Vocabularies

Some approaches to access control are discussed below.

5.1.1 W3C WebAccessControl

• Web Access Control wiki page

Grant Read|Write|Append|Control permissions for a principle identified by a URL to access another URL.

5.1.1.1 Examples

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

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

This means that anyone may read card.rdf, and <card#i> can write it.

[acl:accessTo <card.rdf>; acl:mode acl:Read; acl:agentClass foaf:Agent].
[acl:accessTo <card.rdf>; 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.

5.1.2 Shi3ld

• Shi3ld

Shi3ld is an attribute-based authorization framework to protect RDF named graphs. Access Policies are defined using Semantic Web languages only (RDF and SPARQL).

In the example below, the policy :policy1 protects the named graph :ng1 from read access (i.e., SPARQL SELECT, CONSTRUCT and ASK queries). The policy contains a set of Access Conditions (:acs1) that includes the access condition :ac1. The latter allows access only if the user is located in a point of interest (POI) at given geo coordinates, with a radius of 500m.

   :policy1 a s4ac:AccessPolicy;
     4ac:appliesTo :ng1;
     s4ac:hasAccessPrivilege [a s4ac:Read];
     s4ac:hasAccessConditionSet :acs1.

   :acs1 a s4ac:AccessConditionSet;
     s4ac:ConjunctiveAccessConditionSet;
     s4ac:hasAccessCondition :ac1.
   
   :ac1 a s4ac:AccessCondition;
      s4ac:hasQueryAsk
        """ASK {
                 ?context a prissma:Context;
                     prissma:environment ?env.
                 ?env prissma:currentPOI ?poi.
                 ?poi prissma:radius "500";
                      foaf:based_near ?p.
                 ?p  geo:lat "43.615811";   
                     geo:long "7.068532".}""".

5.1.3 Oracle Triple-based Access Control

The Oracle RDF store, which is based on the Oracle Relational database, offers two granularities of access control: Model-based access control, based on a database view, allows access control through Grant/Revoke operations on the view, and triple-level access control through Oracle label security.

To enable triple-level security, triples and users are tagged with security labels. Labels determine the sensitivity of the data or the rights a person must posses in order to read or write the data. If the user’s read label dominates the triple's read label, the user can access the triple. If the user’s write label dominates the triple's write label, the user can update the triple. A Security Administrator assigns labels to users.

If the user writes a SPARQL query against the data, only the triples she is allowed to read are returned. Label information is hidden from the user.

5.2 Agent Identification

Below are some well known identity systems. These are well known ways of tying a user to a string, known as a Principal. These are not incompatible as shown in the Identity Interoperability wiki page.

5.2.1 HTTP Basic or Digest

RFC 2617 defines HTTP Basic and Digest authentication mechanisms.

5.2.2 WebID

WebID spec, defined at the WebID Incubator/Community group, is an efficient way using TLS and public key cryptography to identify a user by a URI which can itself be a Linked Data Resource, and so can be managed by LDP. TLS makes it easy to add protection per resource without requiring a resource to be tied to any further authentication end point, and allows for good error reporting ( when enhanced with semantic descriptions ). Attribute Exchange about the user can be done using LDP too.

5.2.3 OpenID

OpenID authentication also allows one to tie an identity to a resource that could be an LDP resource, though usually it is aimed at end users with little technical experience in order to help them log in to remote sites by tying their identity to their blog page. Attribute exchange is done with its own protocol rather than by using an Linked Data system. It also requires a lot of connections to authentify a user successfully, as shown by the OpenId sequence diagram.

5.2.4 BrowserID

BrowserID authentifies an e-mail address using cryptographic keys. It could work together with a WebID URL too as explained by the StackExchange WebID/BrowserID comparison. It requires javascript to be executed by the client - making it less efficient and prone to denial of service attacks as opposed to TLS client authentication.