W3C home > Mailing lists > Public > public-rww@w3.org > May 2014

Fwd: Access Control Note

From: Melvin Carvalho <melvincarvalho@gmail.com>
Date: Thu, 22 May 2014 16:55:19 +0200
Message-ID: <CAKaEYhK3ag8niu3oBjQV7k=U8VtMtG=etBMYKcuYO-jxb6_Fyg@mail.gmail.com>
To: public-rww <public-rww@w3.org>
FYI

---------- Forwarded message ----------
From: Ashok Malhotra <ashok.malhotra@oracle.com>
Date: 22 May 2014 15:34
Subject: Access Control Note
To: "public-ldp-wg@w3.org" <public-ldp-wg@w3.org>


I took a stab at making Access Control ReSpectable.
See attached.  This is, essentially, the contents of the Wiki
in publishable form.

Please take a look and comment.  What would be the next step
for this note?
-- 
All the best, Ashok

  This note discusses usecases and requirements for Access Control for
the Linked
Data Platform WG. <https://www.w3.org/2012/ldp/wiki/Main_Page> 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.<https://www.w3.org/2012/ldp/wiki/Main_Page>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

   - 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.
   - ACG Resource: A resource whose representation contains one or more
   ACGs which the server relies upon to make access control decisions.

  Usecases  Access Control on HTTP manipulation of resources Adam's user
agent attempts:

   1. To READ, UPDATE, CREATE or DELETE, PATCH a resource identified by a
   URL. The server allows or denies the request as specified the by the ACG
   for the resource or request that he authenticate to do it.
   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, Adam would like an explanation for why all or
   part of his request was denied. This helps detect errors.
   4. Adam would ideally like to know before accessing a resource if he
   will be able to perform an action - ie: he may have to authenticate first
   with one of his identities to be able to do something.
        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
               - An Agent must be able to authenticate herself to a server
               with an identifier or as the owner of a token. ( All use cases )
               - Ability to specify a collection of agents, identifying
               agents with URIs, URI patterns, or by description.
(Usecase 3.2.2, 3.2.3)
               - 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)
               - Ability to connect a collection of agents with a
               collection of resources with given access privileges. (
All use cases )
                  The above requirements require the ability, by an
            authorized agent, to CREATE, EDIT, UPDATE relevant ACGs.
               - Ability to specify access privileges at a fine-grained
               level. (Usecase 3.1.2, 3.2.1.2)
               - The server should be able to describe access control
               policies for a resource. (Usecase 3.1.4, 3.3.1, 3.3.2)
               - The server should be able explain the reasons for access
               being disallowed in a machine readable format. (Usecase 3.1.3)
               - A user-agent should be able to find the ACG for a given
               resource.(Usecase 3.1.1)
               - The ability by one user agent to delegate the authority to
               create and edit ACGs to another agent.<(Usecase 3.3.3)/li>
              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.
Received on Thursday, 22 May 2014 14:55:49 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:10:46 UTC