Policy-Driven Negotiations and Explanations on the Semantic Web Daniel Olmedilla L3s Research Center...

Policy-DrivenNegotiations and Explanations

on the Semantic Web

Daniel OlmedillaL3s Research Center / Hannover University

CSL Seminar, SRI InternationalMenlo Park, CA, 24th October 2005

October 24th, 2005CSL Seminar, SRI International 2Daniel Olmedilla

Motivation ScenarioBuying in Internet

Bob wants to access an electronic AI book at “E-Book Store” (a web site he found while surfing in Internet)

Previously, E-Book requires Bob to register providing full name, age, complete address, telephone and e-mail

Bob does not mind to give his full name and age but he does not like to provide his complete address, telephone and e-mail. However, he does not have any other option so he does it (although he does not provide his real address and telephone).

E-Book sells that book. Therefore now it asks Bob to provide his credit card information. Bob would not mind to buy the book because it is not too expensive and he is really interested in reading it. However, he has never heard about E-Book so he decides to not buy it


Traditional Access Controlfor Decentralized Systems

Assumption: I already know you---you have a local account!

Not a member?


Policy-Driven Negotiation (I)General Picture

Every party can define policies to control outsiders’ use of its resources Service access control (security) Credential disclosure control (privacy) Business rules

Decisions are based on parties’ properties

Properties are established iteratively and bilaterally by the disclosure of certificates and declarations, i.e. negotiations

[ Winsborough, Seamons, Jones. Automated Trust Negotiation.DARPA Information Survivability Conference and Exposition, 2000]


Policy-Driven Negotiation (& II)Example: Security & Privacy

Step 1: Alice requests a service from Bob

Step 5: Alice discloses her VISA card credential

Step 4: Bob discloses his BBB credential

Step 6: Bob grants access to the serviceService

BobAlice

Step 2: Bob discloses his policy for the service

Step 3: Alice discloses her policy for VISA


Policy Specification (I)What does policy refers to?

The term policy refers to: Security Policies: pose constraints on the

behavior of a system Trust Management Policies: typically used to

collect user properties in open environments Business Rules: statements about how a

business is done

In addition, associated to policies one needs to execute actions. Therefore also relevant:

Action Languages: used in reactive policy specification to execute actions

[ Bonatti, Shahmehri, Duma, Olmedilla, Nejdl, Baldoni, Baroglio, Martelli, Patti, Coraggio, Antoniou, Peer, Fuchs. Rule-based Policy Specification: State of the Art and Future Work. Project deliverable D1, Working Group I2, EU NoE REWERSE ]


Policy Specification (& II)Integration of Policies

Although many approaches have been described to address the above points, there is no common solution, integrating them all in a single framework.


Protune Rule Language (I)Specification

Based on normal logic program A ← L1,…,Ln

Categories of predicates are Decision Predicates:

Allow(): queried by the negotiation for access control decisions

Sign(): used to issue statements signed by the principal owning the policy

Abbreviation/Abstraction Predicates Constraint Predicates: comprise usual equality and

disequality predicates State Predicates: decisions according the state

State Query Predicates: read the state without modifying it

Provisional Predicates: may be made true by means of associated actions that may modify the current state

- E.g. credential(C,K), declaration(), logged(X,logfile_name)[ Bonatti, Olmedilla. Driving and Monitoring Provisional Trust Negotiation with Metapolicies. IEEE Policies for Distributed Systems and Networks (POLICY 2005) ]


Protune Language (II)Policy Filtering Example

allow(download(‘file1234.pdf’)) ?

Alice Bob

allow(download(Resource)) ← authenticated(User), hasSubscription(User).

authenticated(User) ← credential(C), C.type:’id’.

authenticated(User) ← declaration([ user=User, password=P ]), passwd(User,P).hasSubscription(‘Alice’).hasSubscription(‘John’).

passwd(‘Alice’,’$1234ab3’).passwd(‘John’, ‘8%%&ca’).

allow(download(Resource)) ← public(Resource).allow(download(Resource)) ← public(Resource).

allow(download(Resource)) ← authenticated(User), hasSubscription(User).

authenticated(User) ← credential(C), C.type:’id’.

authenticated(User) ← declaration([ user=User, password=P ]), passwd(User,P).

Alice does not know what authenticated means

Only shared predicatesOnly shared predicates

blurred( )

blurred( )

‘file1234.pdf’

is not public


Protune Language (III)Filtering Process

Filter non-applicableand irrelevant rules

Pol

Compile applicable,non-public rules

P1

Partial evaluation ofpublic rules

P2

Executeimmediate actions

P3

Evaluatelocal provisional literals

P4

Blur deferredstate conditions

Filter irrelevant policiesdue to blurring

P6

Replace provisional state predicates with actions

P7

Anonymizeabbreviation predicates

P8

P5

P9


Protune Language (III)Metapolicies

Attribute Domain Range

action provisional predicates commands

actor provisional predicates self, peer

aggregation_method

cost and sensitivity attributes

max, min, sum, adopt(Predicate)

cost provisional predicates number

evaluation state predicates immediate, delayed, concurrent

expected_outcome provisional predicates success, failure, undefined, unknown

explanation literals and rules string expression

ontology abbreviation predicates, credentials, declarations, actions

URI

predicate literals predicate names

selection_method negotiator certain_first, order(attribute_list), adopt(Predicate)

sensitivity predicates, literals, rules public, private, not_applicable

type predicates, literals abbreviation, constraint, decision, state_predicate, provisional, state_query


PROTUNE Policy Language (& IV)Metapolicy Examples

table(Key,Data).evaluation:immediate ← ground(Key).

logged(Msg,File).action:’echo’+Msg+’>’+File.

credential(_).ontology:URI.

abbrev(_).explanation:”this condition checks…”


Application ScenarioNegotiating on the Web

[ Gavriloaie, Nejdl, Olmedilla, Seamons, Winslett. No Registration Needed: How to Use Declarative Policies and Negotiation to Access Sensitive Resources on the Semantic Web. 1st European Semantic Web Symposium ]


Policy Answering & Explanations (I)Motivation

Suppose Alice's request is rejected

She may want to ask questions like: Why didn't you accept my credit card?

Other possible queries How-to queries What-if queries

Would I get the special discount on financial products X if I were locally employed?


Policy Answering & Explanations (& II)Analysis and Requirements

Easy instantiation in any given app. domain One step extra creating literal verbalization rules

Performance Should not increase significantly the computational load of

servers Constructed at client side

Explanation method Focus on the parts of the search space relevant to the user Concise (pruned irrelevant information) vs. detailed

Presentation strategies Different kind of queries: why/why-not, how-to, what-if Breaking up and pruning of proofs and explanations Explanation navigation: Proof as a (potentially cyclic)

hypertext Based on

Set of (computed) answer substitutions- Tabled explanation structure

Verbalization patterns[ Bonatti, Olmedilla, Peer. Advance Policy Queries.

Project deliverable D4, Working Group I2, EU NoE REWERSE ]


How-To Queries (I) how-to: allow(download(Resource))

TO MAKE SURE THAT it is allowed to download Resource

NOTHING NEEDS TO BE DONE IFResource is public [details]

ALTERNATIVELY

PLEASE MAKE SURE THAT FOR SOME UserUser is authenticated [details]ANDUser has subscription [details]

ALTERNATIVELY

PLEASE MAKE SURE THAT FOR SOME UserUser is authenticated [details]ANDUser has paid for Resource [details]

POLICYallow(download(Resource)) ← public(Resource).

allow(download(Resource)) ←authenticated(User),hasSubscription(User).

allow(download(Resource) ←authenticated(User),paid(User,Resource).

METAPOLICYallow(download(Resource)).explanation:

[it,is,allowed,to,download,Resource].

public(Resource).explanation:[Resource,is,public].

authenticated(User).explanation:[User,is,authenticated].

hasSubscription(User).explanation:[User,has,subscription].

paid(User,Resource).explanation:[User,has,paid,for,Resource].


How-To Queries (& II) how-to: authenticated(User)

TO MAKE SURE THAT User is authenticated

PLEASE MAKE SURE THAT FOR SOMEUser, Credential and CA

Credential has type ‘id’, name User and issuer CAAND

CA is trusted for ‘id’ [details]which has solutions (click for proof details):[Credential=c012,User=‘John’,CA=‘L3S’][apply it][Credential=c015,User=‘John’,CA=‘SRI’][apply it]

ALTERNATIVELY

PLEASE DECLARE THATusername = User and password = P

[info]WHERE

P is the correct password for User

POLICYauthenticated(User) ←

credential(Credential),Credential.type:’id’,Credential.name:User,Credential.issuer:CA,blurred(trusted_for(CA,’id’)).

authenticated(User) ← declaration([ user=User, password=P ]), blurred(passwd(User,P)).

METAPOLICYauthenticated(User).explanation:

[User,is,authenticated].

trusted_for(CA,Type).explanation:[CA,is,trusted,for,Type].

passwd(User,P).explanation:[P,is,the,correct,password,for,User].

Existence of solutions may be applied in order to see its global consequences


Why-Not Queries (I)concise why-not: allow(download(paper14.pdf)

I CAN’T PROVE THATit is allowed to download paper14.pdf

BECAUSE

Rule [r3] is not applicable:THERE IS NO User SUCH THAT

User is authenticated [details]

AND

Rule [r4] is not applicable:THERE IS NO User SUCH THAT

User is authenticated [details] MOREOVERTHERE IS NO User SUCH THAT

User has paid for paper14.pdf [details]

POLICY[r3]: allow(download(Resource)) ←

authenticated(User),hasSubscription(User).

[r4]: allow(download(Resource) ←authenticated(User),paid(User,Resource).

METAPOLICYallow(download(Resource)).explanation:

[it,is,allowed,to,download,Resource].

public(Resource).explanation:[Resource,is,public].

authenticated(User).explanation:[User,is,authenticated].

hasSubscription(User).explanation:[User,has,subscription].

paid(User,Resource).explanation:[User,has,paid,for,Resource].

Pruning: User is not authenticated so it makes no sense to inspect her

subscriptions

“authenticated” depends on a credential. “hasSubscription” depends on

“authenticated”


Why-Not Queries (& II)concise why-not: authenticated(User)

I CAN’T FIND ANY User SUCH THATUser is authenticated

BECAUSE

c012 is a credential withtype ‘id’,name ‘John’ and issuer ‘L3S’[details]BUTIT IS NOT THE CASE THAT‘L3S’ is trusted for ‘id’ [details]

AND

Rule [r7] is not applicable:THERE ARE NO User AND P SUCH THATIT HAS BEEN DECLARED THATusername = User and password = P

POLICY[r6]: authenticated(User) ←

credential(Credential),Credential.type:’id’,Credential.name:User,Credential.issuer:CA,blurred(trusted_for(CA,’id’)).

[r7]: authenticated(User) ← declaration([ user=User, password=P ]), blurred(passwd(User,P)).

METAPOLICYauthenticated(User).explanation:

[User,is,authenticated].

trusted_for(CA,Type).explanation:[CA,is,trusted,for,Type].

passwd(User,P).explanation:[P,is,the,correct,password,for,User].


Advanced Explanations (I)Tabled Explanation Structure

Given atom A and a program PExplanation node X = set of (r,θ) such that

Navigation links: Detail Links: expand proof details for subgoal

Refinement Links: apply answer substitutions locally

Explanation Graph = XG = (V,ED, ER) Explanation Structure = Graph + computed

answers

PrrheadAmgurXAentry |))(,(,)(

)(),( some and , somefor iff 2121 LentryXrbodyLXrXX DL

, andon substitutianswer computed a is

)( some and , somefor iff

2

121

rX

rbodyLXrXX R


Advanced Explanations (& II)Novel Aspects

Tabled explanation structure vs. single derivations or proof trees

Show simultaneously different proof attempts Allow to see local (intra-proof) and global (inter-proof)

Heuristics to remove irrelevant information But provide full explanations too

Heuristics are generic, domain independent Lightweight and scalable

Most of computational effort is delegated to clients


REWERSE WG I2 (I)Mission

Integration of policies Security policies, Trust management Business rules, Quality of service specs.

Enhance user control and awareness on system behavior

Reduce the cost of building and maintaining cooperative systems


REWERSE WG I2 (& II)Current Actions

Adopt a rule-based policy specification language: PROTUNE Flexible and structurally similar to the natural

way policies are expressed

Advanced explanation mechanisms To help the user to understand what policies

prescribe and control

Controlled Natural Language front-end To translate natural language text into rules Generate automatically explanations in natural

language


Further WorkOther REWERSE I2 Objectives

Negotiation Strategies

Integration of policy-based and reputation-based trust management

Integrate event-condition-action (ECA) rules

Natural language front-end to the policy domain

Natural Language Processing (NLP) Automatic generation of natural language explanations

from proofs and filtered policies


Questions?

[email protected] - http://www.l3s.de/~olmedilla/

Thanks!


NEESgrid Linux Cluster

Alice Smith

1Mutual Authentication

(M.A.)

GridFTPServer

RLS

2Alice submits a job

0aRequest previously

stored proxycertificate

MyProxy CredentialRepository

0bReceive proxy

certificate

job

3Delegate proxy

certificate

M.A.

M.A.

M.A. : Mutual Authentication

SRBM.A.

M.A.

Shaketable

Application Scenario (II)Grid Limitations

- Too many Credentials to keep track of- Knowing which credential to use

Authorization may depend on user’s propertiesE.g. user’s affiliation with a project

In large projects, an account per user does not scale

Job must know in advance what credentials will have to be disclosed

- Different sites trust different CA- No way to determine automatically which issuers are trusted


Application Scenarios (& III)Negotiating on the Grid

0. Alicesubmits a job

Alice Smith

Shake TableAccess Manager

3. Alicemembership?

CredentialRepository

4. Alicemembership?

job

1. Authentication

5. AliceBigQuake

membership

6. AliceBigQuake

membership

8. Alice’s jobShakes the table

7. Accessgranted

2. Request

Shaketable

NEESgrid Linux Cluster

[ Basney, Nejdl, Olmedilla, Welch, Winslett. Negotiating Trust on the Grid.2nd Workshop on Semantics in P2P and Grid Computing at WWW’04 ]


Reference Scenario (& IV)Natural Language

We are aiming at natural rule/query formulation Users can download the files in folder

historical_data if the creation date precedes 1/1/2000

Policy enforcement, negotiations, query answering should all be automatically derived from such specifications

Attempto Controlled English


Trust ManagementReputation-based vs Policy-based

Reputation-based Policy-based

trust(A,B, download(file), 80−100) credential(X, VISA),X.type : credit card, X.owner : B .

allow(visaCard)

credential(member(Requester),bbb),trust(self, Requester, buying, X), X

> 0.8.in(trust(X,Y ,A, L), reputation pckg : eval trust()))

accessGranted(Res) credential(X,VISA),X.type : credit card,X.owner : B.Peer 1

Peer 2

Peer 3

Peer 4

0.8

0.5

0.6 0.9

0.2

???

A BTrust Factor

[Staab,Bhargava,Lilien,Rosenthal,Winslett,Sloman,Dillon,Chang,Hussain,Nejdl,Olmedilla,Kashya The Pudding of Trust. IEEE Intelligent Systems Journal, Vol. 19(5), Sep./Oct. 2004 ]

[ Bonatti, Duma, Olmedilla, Shahmehri. An Integration of Reputation-based and Policy-based Trust Management. Submitted for Publication ]

Date post:	19-Dec-2015
Category:	Documents
View:	216 times
Download:	2 times

Policy-Driven Negotiations and Explanations on the Semantic Web Daniel Olmedilla L3s Research Center...

Documents