Re: Get rid of foaf dependency in ACLs?

On 25 January 2016 at 01:55, Kingsley Idehen <kidehen@openlinksw.com> wrote:

> On 1/24/16 2:54 AM, Melvin Carvalho wrote:
>
> I wanted to highlight this issue raised by Sandro Hawke relating to
>
> https://www.w3.org/wiki/WebAccessControl
>
> "Servers are required to recognize the class *foaf:Agent* as the class of
> all agents. This indicates that the given access is public. In some cases
> this will mean that authentication is therefore not required, and may be
> skipped. When a resource is being written, however, it may be necessary to
> associate the change with some kind of ID for accountability purposes."
>
> Here is the issue:
>
> https://github.com/solid/solid/issues/35
>
> I think proposal is to change this to rdf : Resource to be more general.
>
> Any thoughts on this?
>
>
> I don't believe ACLs are foaf:Agent specific. When I make an
> acl:authorization instance, the object of its acl:agent_class relation
> doesn't have to be a foaf:Agent.
>
> [1] http://www.openlinksw.com/c/9NVXKWB -- acl:agent_class relation
> description.
>

Right.

But as LDP is a webization of the UNIX file system.

WebAccessControl is roughly a webization of UNIX permissions.

In UNIX permissions you have the concepts:

User
Group
Everyone

We have a webiziation of User namely WebID, a URI that denotes an Agent
(not necessarily FOAF, but that is the hint).

Perhaps it's possible to specify everyone and group more clearly?

Everyone -- An Agent?  A FOAF Agent?  anyURI?
Group -- A FOAF Group or something else?

As a server, how do we check membership in a group, I think is the question?


> --
> Regards,
>
> Kingsley Idehen 
> Founder & CEO
> OpenLink Software
> Company Web: http://www.openlinksw.com
> Personal Weblog 1: http://kidehen.blogspot.com
> Personal Weblog 2: http://www.openlinksw.com/blog/~kidehen
> Twitter Profile: https://twitter.com/kidehen
> Google+ Profile: https://plus.google.com/+KingsleyIdehen/about
> LinkedIn Profile: http://www.linkedin.com/in/kidehen
> Personal WebID: http://kingsley.idehen.net/dataspace/person/kidehen#this
>
>

Received on Monday, 25 January 2016 07:15:04 UTC