- From: Ashok Malhotra <ashok.malhotra@oracle.com>
- Date: Mon, 22 Apr 2013 18:26:28 -0400
- To: public-ldp-wg@w3.org
Hi Andy: Sorry for not relying to your earlier query. The architecture I had in mind is a LDP server on top of a a persistent store. That is why I said that the access control would be provided by the persistent store. Clearly, you could build an LDP server that incorporated a persistent store, in which case the access control would would be provided by the LDP server -- or, more accurately the persistent store part of the LDP server. I can change the wording to reflect that. All the best, Ashok On 4/22/2013 6:36 AM, Andy Seaborne wrote: > > > On 21/04/13 20:42, Ashok Malhotra wrote: >> I added some material based on our discussion last week and mail from >> Serena and Henry. If we agree on the direction, what more should we add >> to create the WG Note? >> >> Access Control >> >> Access Control is a mechanism to enable or deny permissions to entities >> - individuals, groups of individuals or organizations - to perform >> operations on resources. The entities have to be authenticated and >> identified and, perhaps, added to a group. >> >> In the case of LDP the resources are LDP resources but the access >> control may operate at different granularities: RDF documents, named >> graphs or individual triples. The operations are read, update, create >> and delete. >> >> For example, as discussed in http://www.w3.org/wiki/WebAccessControl >> access privileges can be requested as below: >> >> @prefix acl: <http://www.w3.org/ns/auth/acl#> . >> >> @prefix foaf: <http://xmlns.com/foaf/0.1/> . >> >> [acl:accessTo <card>; acl:mode acl:Read; acl:agentClass foaf:Agent]. >> >> [acl:accessTo <card>; acl:mode acl:Read, acl:Write;acl:agent <card#i>]. >> >> This means that anyone may read card, and <card#i> can write it. >> >> Typically, Access Control will be provided by the storage mechanism and >> not the LDP server itself. > > I can not reconcile this "provided by the storage mechanism, not the server itself" with the earlier point about "perform operations on resources". > > Could you please explain this? > > Andy > > And also: > http://lists.w3.org/Archives/Public/public-ldp-wg/2013Apr/0041.html > >> Thus, requests such as above will need to be >> mapped to the capabilities of the server. >> The access control mechanism isn't in the purview of the LDP standard, >> so what can we say about >> access control? What can we ask the server to provide? >> >> 1. How are entities authenticated? Can we require the use of WebID or >> OpenID for example? >> Can we even recommend that one of these be used? >> >> LOW BAR: The storage system provides its own mechanism for >> authenticating and identifying entities e.g username/password >> HIGH BAR: Storage system accepts a URL which points to a set of >> credentials identifying entities. Authorization is orthogonal. >> >> 2. What is the granularity of access control? >> >> LOW BAR: RDF resources >> HIGH BAR: A regex that identifies individual triples >> >> OTHER REQUIREMENTS .. >> >> We can add these with a MAY or SHOULD when no countervailing security considerations apply. >> >> >> 3. If access is denied, some explanation of why it was denied. For >> example, "Could not verify one of user's principals" or "Network problem >> during authentication" or "User not authorized to update" >> >> 4. Ability to discover the access control policy as it applies to some >> set of resources. >> >> >> -- >> All the best, Ashok >
Received on Monday, 22 April 2013 22:27:09 UTC