Access Control Note July 3, 2014 bblfish
authorAshok Malhotra <>
Thu, 03 Jul 2014 16:28:05 -0400
changeset 680 6757f7abc1a6
parent 629 25851aac7002
Access Control Note July 3, 2014
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/AccessControl.html	Thu Jul 03 16:28:05 2014 -0400
@@ -0,0 +1,224 @@
+<!DOCTYPE html>
+  <head>
+    <title>LDP Access Control</title>
+    <meta charset='utf-8'>
+    <script src=''
+            async class='remove'></script>
+    <script class='remove'>
+      var respecConfig = {
+          // specification status (e.g. WD, LCWD, WG-NOTE, etc.). If in doubt use ED.
+          specStatus:           "WG-NOTE",
+          // the specification's short name, as in
+          shortName:            "LDP-AC",
+          // if your specification has a subtitle that goes below the main
+          // formal title, define it here
+          subtitle   :  "Usecases and Requirements for Access Control for the Linked Data Platform",
+          // if you wish the publication date to be other than the last modification, set this
+          // publishDate:  "2009-08-06",
+          // if the specification's copyright date is a range of years, specify
+          // the start date here:
+          // copyrightStart: "2005"
+          // if there is a previously published draft, uncomment this and set its YYYY-MM-DD date
+          // and its maturity status
+          // previousPublishDate:  "1977-03-15",
+          // previousMaturity:  "WD",
+          // if there a publicly available Editor's Draft, this is the link
+          // edDraftURI:           "",
+          // if this is a LCWD, uncomment and set the end of its review period
+          // lcEnd: "2009-08-05",
+          // editors, add as many as you like
+          // only "name" is required
+          editors:  [
+              {
+                  name:       "Ashok Malhotra"
+              ,   mailto:     "[email protected]"
+              ,   company:    "Oracle America, Inc."
+              ,   companyURL: ""
+              },
+          ],
+          // name of the WG
+          wg:           "Linked Data Platform WG",
+          // URI of the public WG page
+          wgURI:        "",
+          // name (without the of the public mailing to which comments are due
+          wgPublicList: "[email protected]",
+          // URI of the patent status for this WG, for Rec-track documents
+          // !!!! IMPORTANT !!!!
+          // This is important for Rec-track documents, do not copy a patent URI from a random
+          // document unless you know what you're doing. If in doubt ask your friendly neighbourhood
+          // Team Contact.
+          wgPatentURI:  "",
+      };
+    </script>
+  </head>
+  <body>
+    <section id='abstract'>
+      <p>
+        This note discusses usecases and requirements for Access Control for the 
+		<a href="">Linked Data Platform WG.</a> 
+		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. 
+      </p>
+    </section>
+    <section id='sotd'>
+      <p>
+        While the <a href="">Linked Data Platform WG.</a> 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.    
+      </p>
+    </section>
+    <section>
+      <h2>Access Control</h2>
+      <p>
+        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).
+		</p>
+		<p>
+        When an agent requests a collection of resources it gets to see only those resources or parts of resources 
+		it is authorized for.</p>
+		<p>
+		Depending on the granularity, the access control mechanisms may affect performance, but should not affect 
+		semantics.</p>
+		<p>
+		For access control to come into play, the server must restrict some operations on some resources. 
+		</p>
+		</section>
+		<section>
+	  <h2>Terminology</h2>
+	  <ul>
+	  <li>ACG: An Access Control Graph describes which an agent or a group of agents can have some mode of access to a resource, 
+	  or collection of resources.</li>
+	  <li>ACG Resource: A resource whose representation contains one or more ACGs which the server relies 
+	  upon to make access control decisions.</li>
+	  </ul>
+    </section>
+	<section>
+	<h2>Usecases</h2>
+	<section>
+	<h3>Access Control on manipulation of resources via HTTP</h3>
+	Adam's user agent attempts:
+	<ol>	
+    <li>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.</li>
+    <li>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.</li>
+    <li>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.
+	</li>
+    <li>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.
+	</li>
+	<ol>
+	</section>
+	<section>
+	<h3>Editability of Access Control Rules using HTTP</h3>
+	<ol>
+	<li>
+    Bart's user agent logs on to a server and requests:
+	<ol>
+        <li>The ability to read a group of related resources such as all the papers presented at a conference.</li>
+        <li>The ability to update an attribute of related resources, for example, to add a copyright notice to each resource.
+    	</ol></li>
+	<li>Employees with job titles VP or SVP can sign (update) supplier contracts.</li>
+    <li>Charlie, the Webmaster, would like to grant read access to the papers presented at a conference to all the 
+	people who attended the conference.</li>
+	<ol>
+	</section>
+	<section>
+	<h3>User Interface Scenarios</h3>
+	Eddie's HTTP based user agent would like to provide a user interface to allow, where possible, Eddie to 
+	<ol>
+	<li>Know if he can edit or delete a resource.</li>
+    <li>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 )</li>
+	<li>Allow Eddie to edit the access control rules for a resource such as:
+	<ol>
+        <li>Allow friends of his to access a document.</li>
+        <li>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.</li>
+        <li>Allow all the members of the LDP WG to create and edit resources including LDP Containers under a 
+		specific URL pattern.</li>
+		<li>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.</li>
+		<li>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.</li> 
+	</ol>
+	</ol>
+	</section>
+	<section>
+	<h2>Requirements</h2>
+	<ul>
+	<li>An Agent must be able to authenticate herself to a server with an identifier or as the owner of a token. 
+	( All use cases )</li>
+    <li>Ability to specify a collection of agents, identifying agents with URIs, URI patterns, or by description. 
+	(Usecase 3.2.2, 3.2.3)</li>
+    <li>Ability to specify a collection of resources, identified by URIs or URI patterns or by description,
+	with a specified access policy. (Usecase 3.2.1, 3.2.3)</li>
+    <li>Ability to connect a collection of agents with a collection of resources with given access privileges. 
+	( All use cases )</li>
+	</ul>
+	&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;The above requirements require the ability, by an authorized agent, to CREATE, EDIT, UPDATE relevant ACGs. 
+	<ul>
+	<li>Ability to specify access privileges at a fine-grained level. (Usecase 3.1.2,</li>
+    <li>The server should be able to describe access control policies for a resource. (Usecase 3.1.4, 3.3.1, 3.3.2)</li>
+    <li>The server should be able explain the reasons for access being disallowed in a machine readable format.
+	(Usecase 3.1.3)
+	</li>
+    <li>A user-agent should be able to find the ACG for a given resource.(Usecase 3.1.1)</li>
+	<li>The ability by one user agent to delegate the authority to create and edit ACGs to another agent.<(Usecase 3.3.3)/li>
+	</ul>
+	</section>
+	<section>
+	<h2>Outline of a Charter for a Access Control WG</h2>
+	<p>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.</p>
+	<p>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.
+	</p>
+	<p>
+	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.</p>
+	<p>The WG will need to decide whether it also wants to define fine-grained access control at an attribute level.</p>
+<li>Define the collections that are part of the ACG and define how a collection of agents is connected to a 
+connection of resources.</li>
+<li>Define how ACGs can be created and edited and how these rights can be delegated.</li>
+<li>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.</li>
+	</section>
+	</section>
+  </body>