--- a/AccessControl.html Mon Aug 25 13:32:25 2014 -0700
+++ /dev/null Thu Jan 01 00:00:00 1970 +0000
@@ -1,220 +0,0 @@
-<!DOCTYPE html>
-<html>
- <head>
- <title>LDP Access Control</title>
- <!-- Changed by: , 25-Aug-2014 -->
- <meta charset='utf-8'>
- <script src='https://www.w3.org/Tools/respec/respec-w3c-common'
- 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 http://www.w3.org/TR/short-name/
- shortName: "ldp-acr",
-
- // 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: "https://dvcs.w3.org/hg/ldpwg/raw-file/default/AccessControl.html",
-
- // 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: "ashok.malhotra@oracle.com"
- , company: "Oracle America, Inc."
- , companyURL: "http://www.oracle.com/"
- },
- ],
-
- // name of the WG
- wg: "Linked Data Platform WG",
-
- // URI of the public WG page
- wgURI: "http://www.w3.org/2012/ldp",
-
- // name (without the @w3c.org) of the public mailing to which comments are due
- wgPublicList: "public-ldp-comments@w3.org",
-
- // 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: "http://www.w3.org/2004/01/pp-impl/55082/status",
- // !!!! IMPORTANT !!!! MAKE THE ABOVE BLINK IN YOUR HEAD
- };
- </script>
- </head>
- <body>
- <section id='abstract'>
- <p>
- This note discusses usecases and requirements for Access Control for the
- <a href="https://www.w3.org/2012/ldp/wiki/Main_Page">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="https://www.w3.org/2012/ldp/wiki/Main_Page">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 or individual triples.
- The operations are typically create, read, update, and delete (CRUD) but other operations can easily be accomodated by
- this design.
- </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 the permitted modes of access for particular agents to apecific 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 by the ACG for the Resource.</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
- the capability to read a group of related resources such as all the papers presented at a conference.</li>
- </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 itself 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>
-
- <p>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, 3.2.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>
-<section>
-<h2>Deliverables</h2>
-<ul>
-<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>
-</ul>
-</section>
- </section>
- </section>
-
-
- </body>
-</html>
--- a/AccessControlRespec.html Mon Aug 25 13:32:25 2014 -0700
+++ /dev/null Thu Jan 01 00:00:00 1970 +0000
@@ -1,219 +0,0 @@
-<!DOCTYPE html>
-<html>
- <head>
- <title>LDP Access Control</title>
- <meta charset='utf-8'>
- <script src='https://www.w3.org/Tools/respec/respec-w3c-common'
- 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 http://www.w3.org/TR/short-name/
- shortName: "LDP-ACR",
-
- // 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: "2014-08-22",
-
- // 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: "http://berjon.com/",
-
- // 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: "ashok.malhotra@oracle.com"
- , company: "Oracle America, Inc."
- , companyURL: "http://www.oracle.com/"
- },
- ],
-
- // name of the WG
- wg: "Linked Data Platform WG",
-
- // URI of the public WG page
- wgURI: "https://www.w3.org/2012/ldp/wiki/Main_Page",
-
- // name (without the @w3c.org) of the public mailing to which comments are due
- wgPublicList: "public-ldp-comments@w3.org",
-
- // 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: "",
- // !!!! IMPORTANT !!!! MAKE THE ABOVE BLINK IN YOUR HEAD
- };
- </script>
- </head>
- <body>
- <section id='abstract'>
- <p>
- This note discusses usecases and requirements for Access Control for the
- <a href="https://www.w3.org/2012/ldp/wiki/Main_Page">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="https://www.w3.org/2012/ldp/wiki/Main_Page">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. This is a First Public Working Draft.
- </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 or individual triples.
- The operations are typically create, read, update, and delete (CRUD) but other operations can easily be accomodated by
- this design.
- </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 the permitted modes of access for particular agents to apecific 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 by the ACG for the Resource.</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
- the capability to read a group of related resources such as all the papers presented at a conference.</li>
- </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 itself 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>
-
- <p>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, 3.2.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>
-<section>
-<h2>Deliverables</h2>
-<ul>
-<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>
-</ul>
-</section>
- </section>
- </section>
-
-
- </body>
-</html>
--- a/LDP Access ControlNoRespec.htm Mon Aug 25 13:32:25 2014 -0700
+++ /dev/null Thu Jan 01 00:00:00 1970 +0000
@@ -1,406 +0,0 @@
-<!DOCTYPE html>
-<html dir="ltr" typeof="bibo:Document " about="" property="dcterms:language" content="en" lang="en"><head>
-<meta http-equiv="content-type" content="text/html; charset=UTF-8">
- <title>LDP Access Control</title>
- <meta charset="utf-8">
-
-
- <style>/*****************************************************************
- * ReSpec 3 CSS
- * Robin Berjon - http://berjon.com/
- *****************************************************************/
-
-/* --- INLINES --- */
-em.rfc2119 {
- text-transform: lowercase;
- font-variant: small-caps;
- font-style: normal;
- color: #900;
-}
-
-h1 acronym, h2 acronym, h3 acronym, h4 acronym, h5 acronym, h6 acronym, a acronym,
-h1 abbr, h2 abbr, h3 abbr, h4 abbr, h5 abbr, h6 abbr, a abbr {
- border: none;
-}
-
-dfn {
- font-weight: bold;
-}
-
-a.internalDFN {
- color: inherit;
- border-bottom: 1px solid #99c;
- text-decoration: none;
-}
-
-a.externalDFN {
- color: inherit;
- border-bottom: 1px dotted #ccc;
- text-decoration: none;
-}
-
-a.bibref {
- text-decoration: none;
-}
-
-cite .bibref {
- font-style: normal;
-}
-
-code {
- color: #C83500;
-}
-
-/* --- TOC --- */
-.toc a, .tof a {
- text-decoration: none;
-}
-
-a .secno, a .figno {
- color: #000;
-}
-
-ul.tof, ol.tof {
- list-style: none outside none;
-}
-
-.caption {
- margin-top: 0.5em;
- font-style: italic;
-}
-
-/* --- TABLE --- */
-table.simple {
- border-spacing: 0;
- border-collapse: collapse;
- border-bottom: 3px solid #005a9c;
-}
-
-.simple th {
- background: #005a9c;
- color: #fff;
- padding: 3px 5px;
- text-align: left;
-}
-
-.simple th[scope="row"] {
- background: inherit;
- color: inherit;
- border-top: 1px solid #ddd;
-}
-
-.simple td {
- padding: 3px 10px;
- border-top: 1px solid #ddd;
-}
-
-.simple tr:nth-child(even) {
- background: #f0f6ff;
-}
-
-/* --- DL --- */
-.section dd > p:first-child {
- margin-top: 0;
-}
-
-.section dd > p:last-child {
- margin-bottom: 0;
-}
-
-.section dd {
- margin-bottom: 1em;
-}
-
-.section dl.attrs dd, .section dl.eldef dd {
- margin-bottom: 0;
-}
-
-@media print {
- .removeOnSave {
- display: none;
- }
-}
-</style><link href="LDP%20Access%20ControlNoRespec_files/W3C-WG-NOTE.css" rel="stylesheet"><!--[if lt IE 9]><script src='https://www.w3.org/2008/site/js/html5shiv.js'></script><![endif]--></head>
- <body id="respecDocument" role="document" class="h-entry"><div id="respecHeader" role="contentinfo" class="head">
- <p>
-
- <a href="http://www.w3.org/"><img src="LDP%20Access%20ControlNoRespec_files/w3c_home.png" alt="W3C" height="48" width="72"></a>
-
- </p>
- <h1 class="title p-name" id="title" property="dcterms:title">LDP Access Control</h1>
-
- <h2 property="bibo:subtitle" id="subtitle">Usecases and Requirements for Access Control for the Linked Data Platform</h2>
-
- <h2 id="w3c-working-group-note-22-august-2014" property="dcterms:issued" datatype="xsd:dateTime" content="2014-08-22T04:00:00.000Z"><abbr title="World Wide Web Consortium">W3C</abbr> Working Group Note <time class="dt-published" datetime="2014-08-22">22 August 2014</time></h2>
- <dl>
-
- <dt>This version:</dt>
- <dd><a class="u-url" href="http://www.w3.org/TR/2014/NOTE-LDP-ACR-20140822/">http://www.w3.org/TR/2014/NOTE-LDP-ACR-20140822/</a></dd>
- <dt>Latest published version:</dt>
- <dd><a href="http://www.w3.org/TR/LDP-ACR/">http://www.w3.org/TR/LDP-ACR/</a></dd>
-
-
-
-
-
-
-
-
- <dt>Editor:</dt>
- <dd class="p-author h-card vcard" rel="bibo:editor" inlist=""><span typeof="foaf:Person"><span property="foaf:name" class="p-name fn">Ashok Malhotra</span>, <a rel="foaf:workplaceHomepage" class="p-org org h-org h-card" href="http://www.oracle.com/">Oracle America, Inc.</a>, <span class="ed_mailto"><a class="u-email email" rel="foaf:mbox" href="mailto:ashok.malhotra@oracle.com">ashok.malhotra@oracle.com</a></span></span>
-</dd>
-
-
-
- </dl>
-
-
-
-
-
- <p class="copyright">
- <a href="http://www.w3.org/Consortium/Legal/ipr-notice#Copyright">Copyright</a> ©
- 2014
-
- <a href="http://www.w3.org/"><abbr title="World Wide Web Consortium">W3C</abbr></a><sup>®</sup>
- (<a href="http://www.csail.mit.edu/"><abbr title="Massachusetts Institute of Technology">MIT</abbr></a>,
- <a href="http://www.ercim.eu/"><abbr title="European Research Consortium for Informatics and Mathematics">ERCIM</abbr></a>,
- <a href="http://www.keio.ac.jp/">Keio</a>, <a href="http://ev.buaa.edu.cn/">Beihang</a>),
-
- All Rights Reserved.
-
- <abbr title="World Wide Web Consortium">W3C</abbr> <a href="http://www.w3.org/Consortium/Legal/ipr-notice#Legal_Disclaimer">liability</a>,
- <a href="http://www.w3.org/Consortium/Legal/ipr-notice#W3C_Trademarks">trademark</a> and
-
- <a href="http://www.w3.org/Consortium/Legal/copyright-documents">document use</a>
-
- rules apply.
- </p>
-
-
- <hr>
-</div>
- <section rel="bibo:Chapter" resource="#abstract" typeof="bibo:Chapter" datatype="" property="dcterms:abstract" class="introductory" id="abstract"><h2 id="h2_abstract" role="heading" aria-level="1">Abstract</h2>
- <p>
- This note discusses usecases and requirements for Access Control for the
- <a href="https://www.w3.org/2012/ldp/wiki/Main_Page">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 rel="bibo:Chapter" resource="#sotd" typeof="bibo:Chapter" id="sotd" class="introductory"><h2 id="h2_sotd" role="heading" aria-level="1">Status of This Document</h2>
-
-
-
- <p>
- <em>This section describes the status of this document at the time of its publication.
- Other documents may supersede this document. A list of current <abbr title="World Wide Web Consortium">W3C</abbr> publications and the
- latest revision of this technical report can be found in the <a href="http://www.w3.org/TR/"><abbr title="World Wide Web Consortium">W3C</abbr> technical reports index</a> at
- http://www.w3.org/TR/.</em>
- </p>
-
- <p>
- While the <a href="https://www.w3.org/2012/ldp/wiki/Main_Page">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. This is a First Public Working Draft.
- </p>
-
- <p>
- This document was published by the <a href="https://www.w3.org/2012/ldp/wiki/Main_Page">Linked Data Platform WG</a> as a Working Group Note.
-
-
- If you wish to make comments regarding this document, please send them to
- <a href="mailto:public-ldp-comments@w3.org@w3.org">public-ldp-comments@w3.org@w3.org</a>
- (<a href="mailto:public-ldp-comments@w3.org-request@w3.org?subject=subscribe">subscribe</a>,
- <a href="http://lists.w3.org/Archives/Public/public-ldp-comments@w3.org/">archives</a>).
-
-
-
-
- All comments are welcome.
-
- </p>
-
-
- <p>
- Publication as a Working Group Note does not imply endorsement by the <abbr title="World Wide Web Consortium">W3C</abbr>
- Membership. This is a draft document and may be updated, replaced or obsoleted by other
- documents at any time. It is inappropriate to cite this document as other than work in
- progress.
- </p>
-
-
-
- <p>
-
- This document was produced by a group operating under the
- <a id="sotd_patent" about="" rel="w3p:patentRules" href="http://www.w3.org/Consortium/Patent-Policy-20040205/">5 February 2004 <abbr title="World Wide Web Consortium">W3C</abbr> Patent
- Policy</a>.
-
-
-
-
- <abbr title="World Wide Web Consortium">W3C</abbr> maintains a <a href="" rel="disclosure">public list of any patent
- disclosures</a>
-
- made in connection with the deliverables of the group; that page also includes
- instructions for disclosing a patent. An individual who has actual knowledge of a patent
- which the individual believes contains
- <a href="http://www.w3.org/Consortium/Patent-Policy-20040205/#def-essential">Essential
- Claim(s)</a> must disclose the information in accordance with
- <a href="http://www.w3.org/Consortium/Patent-Policy-20040205/#sec-Disclosure">section
- 6 of the <abbr title="World Wide Web Consortium">W3C</abbr> Patent Policy</a>.
-
-
- </p>
-
- <p>This document is governed by the <a id="w3c_process_revision" href="http://www.w3.org/2014/Process-20140801/">1 August 2014 <abbr title="World Wide Web Consortium">W3C</abbr> Process Document</a>.
- </p>
-
-
-
-
-
-</section><section id="toc"><h2 id="h2_toc" role="heading" aria-level="1" class="introductory">Table of Contents</h2><ul id="respecContents" role="directory" class="toc"><li class="tocline"><a class="tocxref" href="#access-control"><span class="secno">1. </span>Access Control</a></li><li class="tocline"><a class="tocxref" href="#terminology"><span class="secno">2. </span>Terminology</a></li><li class="tocline"><a class="tocxref" href="#usecases"><span class="secno">3. </span>Usecases</a><ul class="toc"><li class="tocline"><a class="tocxref" href="#access-control-on-manipulation-of-resources-via-http"><span class="secno">3.1 </span>Access Control on manipulation of resources via HTTP</a></li><li class="tocline"><a class="tocxref" href="#editability-of-access-control-rules-using-http"><span class="secno">3.2 </span>Editability of Access Control Rules using HTTP</a></li><li class="tocline"><a class="tocxref" href="#user-interface-scenarios"><span class="secno">3.3 </span>User Interface Scenarios</a></li><li class="tocline"><a class="tocxref" href="#requirements"><span class="secno">3.4 </span>Requirements</a></li><li class="tocline"><a class="tocxref" href="#outline-of-a-charter-for-a-access-control-wg"><span class="secno">3.5 </span>Outline of a Charter for a Access Control WG</a><ul class="toc"><li class="tocline"><a class="tocxref" href="#deliverables"><span class="secno">3.5.1 </span>Deliverables</a></li></ul></li></ul></li></ul></section>
-
-
-
- <section id="access-control">
- <!--OddPage--><h2 id="h2_access-control" role="heading" aria-level="1"><span class="secno">1. </span>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 or individual triples.
- The operations are typically create, read, update, and delete (CRUD)
-but other operations can easily be accomodated by
- this design.
- </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 id="terminology">
- <!--OddPage--><h2 id="h2_terminology" role="heading" aria-level="1"><span class="secno">2. </span>Terminology</h2>
- <ul>
- <li>ACG: An Access Control Graph describes the permitted modes of access for particular agents to apecific 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 id="usecases">
- <!--OddPage--><h2 id="h2_usecases" role="heading" aria-level="1"><span class="secno">3. </span>Usecases</h2>
- <section id="access-control-on-manipulation-of-resources-via-http">
- <h3 id="h3_access-control-on-manipulation-of-resources-via-http" role="heading" aria-level="2"><span class="secno">3.1 </span>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 by the ACG for the Resource.</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>
- </ol></ol></section>
- <section id="editability-of-access-control-rules-using-http">
- <h3 id="h3_editability-of-access-control-rules-using-http" role="heading" aria-level="2"><span class="secno">3.2 </span>Editability of Access Control Rules using HTTP</h3>
- <ol>
- <li>
- Bart's user agent logs on to a server and requests
- the capability to read a group of related resources such as all the papers presented at a conference.</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>
- </ol></ol></section>
- <section id="user-interface-scenarios">
- <h3 id="h3_user-interface-scenarios" role="heading" aria-level="2"><span class="secno">3.3 </span>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>
- </li></ol>
- </section>
- <section id="requirements">
- <h3 id="h3_requirements" role="heading" aria-level="2"><span class="secno">3.4 </span>Requirements</h3>
- <ul>
- <li>An Agent must be able to authenticate itself 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>
-
- <p>The above requirements require the ability, by an authorized agent, to CREATE, EDIT, UPDATE relevant ACGs.
-
- </p><ul>
- <li>Ability to specify access privileges at a fine-grained level. (Usecase 3.1.2, 3.2.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 id="outline-of-a-charter-for-a-access-control-wg">
- <h3 id="h3_outline-of-a-charter-for-a-access-control-wg" role="heading" aria-level="2"><span class="secno">3.5 </span>Outline of a Charter for a Access Control WG</h3>
- <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>
-<section id="deliverables">
-<h4 id="h4_deliverables" role="heading" aria-level="3"><span class="secno">3.5.1 </span>Deliverables</h4>
-<ul>
-<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>
-</ul>
-</section>
- </section>
- </section>
-
-
-
-
-</body></html>
\ No newline at end of file
--- a/LDP Access ControlNoRespec_files/W3C-WG-NOTE.css Mon Aug 25 13:32:25 2014 -0700
+++ /dev/null Thu Jan 01 00:00:00 1970 +0000
@@ -1,89 +0,0 @@
-
-/* Style for a "Working Group Note" */
-
-/*
- Copyright 1997-2003 W3C (MIT, ERCIM, Keio). All Rights Reserved.
- The following software licensing rules apply:
- http://www.w3.org/Consortium/Legal/copyright-software */
-
-/* $Id: base.css,v 1.28 2014-04-22 03:27:49 ijacobs Exp $ */
-
-body {
- padding: 2em 1em 2em 70px;
- margin: 0;
- font-family: sans-serif;
- color: black;
- background: white;
- background-position: top left;
- background-attachment: fixed;
- background-repeat: no-repeat;
-}
-:link { color: #00C; background: transparent }
-:visited { color: #609; background: transparent }
-a:active { color: #C00; background: transparent }
-
-a:link img, a:visited img { border-style: none } /* no border on img links */
-
-a img { color: white; } /* trick to hide the border in Netscape 4 */
-@media all { /* hide the next rule from Netscape 4 */
- a img { color: inherit; } /* undo the color change above */
-}
-
-th, td { /* ns 4 */
- font-family: sans-serif;
-}
-
-h1, h2, h3, h4, h5, h6 { text-align: left }
-/* background should be transparent, but WebTV has a bug */
-h1, h2, h3 { color: #005A9C; background: white }
-h1 { font: 170% sans-serif }
-h2 { font: 140% sans-serif }
-h3 { font: 120% sans-serif }
-h4 { font: bold 100% sans-serif }
-h5 { font: italic 100% sans-serif }
-h6 { font: small-caps 100% sans-serif }
-
-.hide { display: none }
-
-div.head { margin-bottom: 1em }
-div.head h1 { margin-top: 2em; clear: both }
-div.head table { margin-left: 2em; margin-top: 2em }
-
-p.copyright { font-size: small }
-p.copyright small { font-size: small }
-
-@media screen { /* hide from IE3 */
-a[href]:hover { background: #ffa }
-}
-
-pre { margin-left: 2em }
-/*
-p {
- margin-top: 0.6em;
- margin-bottom: 0.6em;
-}
-*/
-dt, dd { margin-top: 0; margin-bottom: 0 } /* opera 3.50 */
-dt { font-weight: bold }
-
-ul.toc, ol.toc {
- list-style: disc; /* Mac NS has problem with 'none' */
- list-style: none;
-}
-
-@media speech {
- h1, h2, h3 { voice-stress: moderate; }
- .hide { speak: none; }
- p.copyright { voice-volume: x-soft; voice-rate: x-fast; }
- dt { pause-before: 63ms; }
-}
-
-
-/* Copyright 1997-2003 W3C (MIT, ERCIM, Keio). All Rights Reserved.
- The following software licensing rules apply:
- http://www.w3.org/Consortium/Legal/copyright-software */
-
-body {
- background-image: url(//www.w3.org/StyleSheets/TR/logo-WG-Note);
-}
-
Binary file LDP Access ControlNoRespec_files/w3c_home.png has changed
--- a/TR/NOTE-ldp-acr-20140825/Overview.html Mon Aug 25 13:32:25 2014 -0700
+++ b/TR/NOTE-ldp-acr-20140825/Overview.html Mon Aug 25 13:41:02 2014 -0700
@@ -141,7 +141,7 @@
<dd><a href="http://www.w3.org/TR/ldp-acr/">http://www.w3.org/TR/ldp-acr/</a></dd>
<dt>Latest editor's draft:</dt>
- <dd><a href="https://dvcs.w3.org/hg/ldpwg/raw-file/default/AccessControl.html">https://dvcs.w3.org/hg/ldpwg/raw-file/default/AccessControl.html</a></dd>
+ <dd><a href="https://dvcs.w3.org/hg/ldpwg/raw-file/default/ldp-acr.html">https://dvcs.w3.org/hg/ldpwg/raw-file/default/ldp-acr.html</a></dd>
--- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/ldp-acr.html Mon Aug 25 13:41:02 2014 -0700
@@ -0,0 +1,220 @@
+<!DOCTYPE html>
+<html>
+ <head>
+ <title>LDP Access Control</title>
+ <!-- Changed by: , 25-Aug-2014 -->
+ <meta charset='utf-8'>
+ <script src='https://www.w3.org/Tools/respec/respec-w3c-common'
+ 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 http://www.w3.org/TR/short-name/
+ shortName: "ldp-acr",
+
+ // 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: "https://dvcs.w3.org/hg/ldpwg/raw-file/default/ldp-acr.html",
+
+ // 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: "ashok.malhotra@oracle.com"
+ , company: "Oracle America, Inc."
+ , companyURL: "http://www.oracle.com/"
+ },
+ ],
+
+ // name of the WG
+ wg: "Linked Data Platform WG",
+
+ // URI of the public WG page
+ wgURI: "http://www.w3.org/2012/ldp",
+
+ // name (without the @w3c.org) of the public mailing to which comments are due
+ wgPublicList: "public-ldp-comments@w3.org",
+
+ // 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: "http://www.w3.org/2004/01/pp-impl/55082/status",
+ // !!!! IMPORTANT !!!! MAKE THE ABOVE BLINK IN YOUR HEAD
+ };
+ </script>
+ </head>
+ <body>
+ <section id='abstract'>
+ <p>
+ This note discusses usecases and requirements for Access Control for the
+ <a href="https://www.w3.org/2012/ldp/wiki/Main_Page">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="https://www.w3.org/2012/ldp/wiki/Main_Page">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 or individual triples.
+ The operations are typically create, read, update, and delete (CRUD) but other operations can easily be accomodated by
+ this design.
+ </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 the permitted modes of access for particular agents to apecific 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 by the ACG for the Resource.</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
+ the capability to read a group of related resources such as all the papers presented at a conference.</li>
+ </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 itself 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>
+
+ <p>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, 3.2.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>
+<section>
+<h2>Deliverables</h2>
+<ul>
+<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>
+</ul>
+</section>
+ </section>
+ </section>
+
+
+ </body>
+</html>
