Annotation-Based Access Control

Copyright 2009 Digital Enterprise Research Institute. All rights reserved.

Digital Enterprise Research Institute www.deri.ie

Annotation-Based Access Control

Peyman Nasirifard

University College Dublin, Dublin, IrelandJuly 1st 2009


Outline

Access control in social platforms How we share resources in real-life Annotation-Based Access Control (patent

pending) Prototype: Uncle-Share

Scenario OR Live Demo Annotation-Based Access Control Add-on (Plug-in) Discussions Conclusion Q and A


Access Control in Social Platforms

One of the key concepts of Web 2.0 platforms is „Sharing“ Sharing needs access control

Problems with current approaches within social and cooperative platforms: Coarse-grained:

– Private vs. Public– Share with individuals

Groups

To move from messaging to sharing: Social-awareness-based access control


Real-Life Access Control

We share resources based on social relationships we attribute to people We may share our credit card details with our parents,

but not with our friends.

We mentally annotate people, meaning of terms may differ between people parent, supervisor, friend, close friend, director, athletic,

honest, etc.

Real-life model can be applied to online model Annotation-Based Access Control

– more natural and flexible


Three Entities and Two Concepts

A Person is an entity with the RDF type Person. A Person is connected to zero or more other Persons. A Person owns zero or more Resources. A Person defines zero or more Policies.

An Annotation is a term or a set of terms that are connected together and aims to describe the Person. Each connection between Persons can be annotated with zero or more Annotations.

A Resource is an entity with the RDF type Resource and is owned by (isOwnedBy) one or more Persons. Resources are in the form of URIs, URLs, and/or short messages.

A Policy is an entity with the RDF type Policy. A Policy is defined by (isDefinedBy) one Person and belongs to (belongsTo) one Resource. A Policy has one Annotation and one Distance.

A Distance is a numerical value which determines the depth that the Policy is valid. The depth is actually the shortest path among two Persons with consideration of Annotations.


Meta-policies (Rules)

Rule: A Person acquires access to a Resource, if and only if (iff) s/he meets all policies that have been defined by Resource owner for that Resource. It means that the Person has been already annotated with the Annotations which are defined in the Policies and s/he is also in the scope of the Policies (i.e. Distance criteria). Multiple Policies that are defined by a Resource owner for a Resource

are ORed, if they have different Distances, otherwise the Policies are ANDed.

Rule: Only the Resource owner is eligible to define Policies for that Resource.

Rule: A private Resource has zero or more Policies, whereas a public Resource has at least one Policy.

Rule: The default Distance for Policies is one.


Extended Version (Patent Pending)


Prototype: Uncle-Share Widget

Login: User login or registration, including full name, user name, and password.

Person: User may add, modify, and annotate contact list.

Resources: User may add resources (URI/short message) and assign them policies.

Shared: User may see the resources that have been shared with him by others. The distance may be set in order to increase or decrease the scope of the shared resources.

Settings: User and server configuration.

Help: Provides a tutorial video and some technical and contact information regarding the platform.


Features

Widget Can be embedded into any Web page or widget platform Syndication, flexibility, portability, and customization.

Service-Oriented-Architecture (SOA) All functionalities are wrapped as services

Ontology-based and RDF-based AJAX (i.e. No additional interations with the server) Suggest box

Suggests annotations to end users Currently the suggestions come from the RELATIONSHIP

ontology We used free and open source packages


Embedded Widget (iGoogle and BSCW)


Question

Scenario or Live Demo?


Use Case Scenario


Who Will Access What?

Alice has access to her three resources and www.resource5.com via Bob, because www.resource5.com is accessible to the Bob's contacts that have been annotated as student and have maximum distance one to Bob and Alice fulfils this policy.

Bob has access to his two resources and also two of Alice's resources: www.resource1.com and www.resource2.com.

Tom has access to www.resource4.com which was shared via Bob to him and also www.resource2.com which was shared via Alice to him.

Mary will see the short message from Alice: I_need_to_talk_to_you_please.


Collaboration Vocabulary

CoVoc: A vocabulary for describing collaborations and e-Professionals (mainly researchers)

Five main categories An e-Professional (researcher) collaborates in different projects An e-Professional (researcher) participates in different events like

conferences and workshops and publishes various stuff An e-Professional (researcher) may be part of the university board An e-Professional (researcher) can be involved in industry An e-Professional (researcher) has various online (social) activities

For each category, we proposed some terms writeDeliverableWith, hadCoffeeBreakWith, supervisor, CEO,

readNewsOf We built RDF schema for CoVoc

Extensible for future needs


Mining Tags

Helping users to Tag people with their expertise Our current approach uses log files of shared

workspaces


Prototype: Expert Finder


Who is working with whom?

Helping users to find proxies Our current approach uses log files of shared

workspaces


Prototype: Holmes


HeyStaks

I am a fan of HeyStacks

There are some user interface and privacy issues Out of scope of this presentation

There exist two (or three) main methods for sharing staks in HeyStaks Users can select one or more buddies from their friend

list to share a stak with them. Users can enter the email addresses of other users to

share a stak with them. Maybe based on groups as well


HeyStaks


HeyStaks

Enabling users to have friends (buddies). Heystaks can also propose some friends: for example,

users with the same email extensions can be friends together and so on.

Adding the feature to enable users to annotate those friends with desired terms. Minining tags based on saved resources

Enabling users to define access control policies for staks based on annotations.

Main access control engine to control the access to resources (staks) based on previous annotations and policies.


Conclusion and Future Work

We presented Annotation-Based Access Control Distance and Annotation are two important factors Propagation of the policies Widget-based prototype can be embedded into any platform Some additional add-on OrbiTeam (BSCW platform) is going to license it for

evaluation purposes

Future Work Recommendar system for people-tags Helping users for determining the appropriate annotation and

distance Integrating this model with BSCW


Thank You!

Q and A

Annotation-Based Access Control

Documents

Transcript of Annotation-Based Access Control