Re: AccessControl : update + inference

On 13 November 2012 02:18, Michiel de Jong <michiel@unhosted.org> wrote:

> i feel the LDP page misses the point. it describes ways in which you
> can use, say, an Oracle database, to describe if certain credentials
> which the client sent are sufficient for a certain action or not. What
> they don't describe is how the client can actually send these
> credentials, and how the server can check their validity.
>
> Let's look at the basic use case first: Alice has a website, and Bob
> is allowed to edit it.
>
> No irrelevant things about 'Bob is within a 500m radius of a certain
> geo location' or 'Alice uses an Oracle database to run her website'.
> Imho that misses the point. There is a small note at the bottom of the
> LDP page saying "identity: WebID". That is what we should be looking
> at, i think:
>
> 1) how does Bob send his credentials
> 2) how does Alice's web server check them
>
> For this, i'm aware of the following options:
>
> - username/password (doesn't scale of course if Bob has many friends)
>

Username / pw is really what got the web going, but the issue is security
and password fatigue.


> - WebID (favourite of this CG!)
>

I would hope we try to be neutral to an extent, and not pick favourites,
but WebID does have a lot of appealing properties, for those that are
linked data oriented.


> - OpenID (sadly probably deprecated)
>

I followed OpenID from almost the start, am a huge fan, in that they
changed the conversation from being about walled gardens and passport, to
about trying to be open.  I had been looking forward to the user centric
elements of openid, but there is little business case to interest the
foundation there, which I can accept.


> - Persona (promising imho)
>

Indeed very promising.  Great UI and lots of buzz.  A couple of things I'd
love to see in persona, is that it becomes an identity system that can
easily interoperate with other identity ecosystems, tho that's not
currently on the roadmap.  Similarly they take a reasonable stance of
saying 'your email provider can read your mail already, so they can already
access your external data'.  This seems an acceptable compromise for the
majority, but some security conscious folks may prefer not to use it for
sensitive data such as financial transactions.


> - Dialback (same)
>

Some buzz around this one, dependent on webfinger, which seems to change
from month to month.


> - Salmon (specific for blogpost-comments, and probably deprecated by
> dialback?)
>

A nice system, but it seems everyone implements it a different way.

Also dont forget
- Cookies
- Unguessable URIs (security by obscurity)
- Trusted shared spaces


>
>
> My 2ct,
> Michiel
>
> On Tue, Nov 13, 2012 at 7:27 AM, Kingsley Idehen <kidehen@openlinksw.com>
> wrote:
> > On 11/12/12 5:19 PM, Andrei SAMBRA wrote:
> >
> > Actually, I wonder if it would be a better idea to move this wiki page
> (on
> > AC) to the RWW wiki, given that it is orthogonal to LDP WG's work. I'll
> > create the stub wiki page and post the link in a reply.
> >
> > +1
> >
> > Kingsley
> >
> >
> > Andrei
> >
> >
> > On Mon, Nov 12, 2012 at 5:16 PM, Kingsley Idehen <kidehen@openlinksw.com
> >
> > wrote:
> >>
> >> On 11/12/12 4:52 PM, Jürgen Jakobitsch wrote:
> >>>
> >>> hi,
> >>>
> >>> since the discussion on AC is apparently taking shape, it might be a
> >>> good time for my questions.
> >>>
> >>> until now we more or less only had examples of AC in action on the
> >>> data-retrieval side (as far as i know at least).
> >>>
> >>> do acl-engines only really work with inference-engines when updating or
> >>> are there recommended ways of dealing with the following example?
> >>>
> >>> prereq.: acl - denies access to resource "x" (say a skos:Concept)
> >>>
> >>> what should happen, when i add the triple?
> >>>
> >>> resource "y" skos:broader resource "x"?
> >>>
> >>>
> >>> there are several scenarios in which this could take place :
> >>>
> >>> 1. should the update request be rejected with full inferencing, because
> >>> it becomes clear the resource "x" is touched?
> >>> 2. what happens in a non-inferencing environment? with that is created
> a
> >>> relation between the two resources and i could construct (sparql-wise)
> >>> whatever i want, which brings me to the idea of never trusting
> >>> application/sparql-results+*...
> >>>
> >>>
> >>> so the crucial point seems to be that ACLs can handle updates more
> >>> flexible, a read and write access denied for a single resource might
> not
> >>> be enough.
> >>>
> >>> any pointer to the most flexible acl-ontology?
> >>> i'm thinking about something like :
> >>>
> >>> denyWriteAccess where resource "x" is the object.
> >>>
> >>> any pointer really appreciated..
> >>
> >>
> >> We we do is have SPARQL ASK as an option for determining conditions.
> That
> >> way, you handle all your desired scenarios as the data (resource)
> publisher.
> >> Basically, we offer:
> >>
> >> 1. basic WebID lists
> >> 2. WebIDs as members of foaf:Groups
> >> 3. SPARQL ASK -- for most complex conditions and custom conditions.
> >>
> >> As for inference, we have this loosely bound to the SPARQL processor
> which
> >> is why we use pragmas to enable inference context in our SPARQL
> >> implementation. I know of not other way to handle the contextual
> fluidity
> >> associated with this subject matter :-)
> >>>
> >>>
> >>> wkr turnguard
> >>>
> >>>
> >>>
> >>>
> >>>
> >>
> >>
> >> --
> >>
> >> Regards,
> >>
> >> Kingsley Idehen
> >> Founder & CEO
> >> OpenLink Software
> >> Company Web: http://www.openlinksw.com
> >> Personal Weblog: http://www.openlinksw.com/blog/~kidehen
> >> Twitter/Identi.ca handle: @kidehen
> >> Google+ Profile: https://plus.google.com/112399767740508618350/about
> >> LinkedIn Profile: http://www.linkedin.com/in/kidehen
> >>
> >>
> >>
> >>
> >>
> >
> >
> >
> > --
> >
> > Regards,
> >
> > Kingsley Idehen
> > Founder & CEO
> > OpenLink Software
> > Company Web: http://www.openlinksw.com
> > Personal Weblog: http://www.openlinksw.com/blog/~kidehen
> > Twitter/Identi.ca handle: @kidehen
> > Google+ Profile: https://plus.google.com/112399767740508618350/about
> > LinkedIn Profile: http://www.linkedin.com/in/kidehen
> >
> >
> >
> >
>
>