Protune Rule-based Policies on the Semantic Web Daniel

Protune Rule-based Policies on the Semantic Web Daniel Olmedilla L 3 S Research Center & Hannover University PUC Seminar Aug. 21 st, 2007, Rio de Janeiro, Brazil

Outline n Introduction n Policy Specification n Integration of Actions § Legacy Systems § Evidences n Negotiations § Filtering n Cooperativeness & Verbalization n Conclusions & Further Work Daniel Olmedilla PUC Seminar 2007 Aug. 21 st, 2007 2

Outline n Introduction n Policy Specification n Integration of Actions § Legacy Systems § Evidences n Negotiations § Filtering n Cooperativeness & Verbalization n Conclusions & Further Work Daniel Olmedilla PUC Seminar 2007 Aug. 21 st, 2007 3

Warning Policy examples Policies specify the behavior of a system and may be applied to many different areas: security, privacy, conversations, business rules, quality of service, etc. The most common application scenario is security. It covers most of the requirements from other areas. Although many of the examples used in this presentation focus on security, it should be clear all the time that its application is not restricted only to security. Daniel Olmedilla PUC Seminar 2007 Aug. 21 st, 2007 4

Introduction Warming Up: Problem Institutions and companies need to control the way they n Make business n Take decisions n Offer their assets n Etc … Generally, they need to control how decisions and actions are taken Daniel Olmedilla PUC Seminar 2007 Aug. 21 st, 2007 5

Introduction Policies Are Everywhere n B 2 B contracts § e. g. quantity flexible contracts, late delivery penalties, etc. n Negotiation § e. g. rules associated with auction mechanisms n Security § e. g. access control policies n Privacy § Information Collection Policies (aka “ P 3 P Privacy Policies”) § Obfuscation Policies n Workflow management § What to do under different sets of conditions n Context aware computing § What service to invoke to access a particular contextual attribute § Context-sensitive preferences [ by Norman Sadeh, Semantic Web Policy Workshop panel, ISWC 2005 ] Daniel Olmedilla PUC Seminar 2007 Aug. 21 st, 2007 6

Introduction Main Challenges Provide a framework where n Behavior is flexible § Can be changed/updated - without re-coding, re-compiling, re-installing, etc… - In a costless manner n Can be managed by administrators/users without needing to be computer experts n Can be understood by normal users n Covers as many different policies as possible Daniel Olmedilla PUC Seminar 2007 Aug. 21 st, 2007 7

Outline n Introduction n Policy Specification n Integration of Actions § Legacy Systems § Evidences n Negotiations § Filtering n Cooperativeness & Verbalization n Conclusions & Further Work Daniel Olmedilla PUC Seminar 2007 Aug. 21 st, 2007 8

Policy Specification A broader notion of Policy The term policy covers: n Security/Privacy policies, Trust management n Business rules n Quality of Service directives n Service-level agreements n and more. . . Daniel Olmedilla PUC Seminar 2007 Aug. 21 st, 2007 9

Policy Specification Examples n Give customers younger than 26 a 20% discount on international tickets n Up to 15% of network bandwidth can be reserved by paying with an accepted credit card n Customers can rent a car if they are 18 or older, and exhibit a driving license and a valid credit card Daniel Olmedilla PUC Seminar 2007 Aug. 21 st, 2007 10

Policy Specification Context-Sensitive Privacy & Security Pervasive Computing n “My colleagues can only see the building I am in and only when they are on company premises” Enterprise Collaboration n “Only disclose inventory levels to customers with past due shipments” Do. D Scenarios (e. g. , coalition forces) n “Only disclose ship departure time after the ship has left” n “Only disclose information specific to the context of ongoing joint operations” Homeland Security & Privacy (e. g. , video surveillance) n “Only allow for facial recognition when a crime scene is suspected” [ by Norman Sadeh, Semantic Web Policy Workshop panel, ISWC 2005 ] Daniel Olmedilla PUC Seminar 2007 Aug. 21 st, 2007 11

Policy Specification Benefits from Rule Based languages n Importance of declarative policy languages § To avoid ambiguous or ill-defined policies § To separate policies and mechanisms § To enable automated policy validation n Proposed logic-based policy languages § To improve readability and maintenance § High-level formulation, more natural for untrained user § To express / integrate different policies (flexibility) [Bonatti, Samarati. Logics for Authorizations and Security. Logics for emerging applications of Databases, 2003 ] Daniel Olmedilla PUC Seminar 2007 Aug. 21 st, 2007 12

Policy Specification Protune Example Policy (I) Decision Predicate allow(rent(Car, Type)) ← credential (DL), DL. type: driving_license, DL. age > 18, available(Car, Type). Abbreviation Predicate Definition available(car 1, ’Ford Focus’). available(car 2, ’VW Polo’). available(car 3, ’Opel Corsa’). Evidence Constraint Predicate Abbreviation Predicate [ Bonatti, Olmedilla. Driving and Monitoring Provisional Trust Negotiation with Metapolicies. IEEE Policies for Distributed Systems and Networks, 2005 ] Daniel Olmedilla PUC Seminar 2007 Aug. 21 st, 2007 13

Policy Specification Protune Example Policy (& II) Specify type with metapolicies allow(rent(Car, Type)). type: decision. available(Car, Type). type: abbreviation. n Simplifies the policy n Controls how the policy is used n Easy extensibility n More on metapolicies later Daniel Olmedilla PUC Seminar 2007 Aug. 21 st, 2007 14

Outline n Introduction n Policy Specification n Integration of Actions § Legacy Systems § Evidences n Negotiations § Filtering n Cooperativeness & Verbalization n Conclusions & Further Work Daniel Olmedilla PUC Seminar 2007 Aug. 21 st, 2007 15

Integration of Actions Exploiting “external” systems Decisions need data, information, and knowledge n Each organization has its own § Already available through legacy software and data § A realistic solution must interoperate with them n Third parties § Credit card sites for validity checking § Credential repositories n Variety of web resources Daniel Olmedilla PUC Seminar 2007 Aug. 21 st, 2007 16

Integration of Actions Policies are not (only) passive objects Policies may specify n Event logging § Failed transactions must be logged § Log downloads of new articles for one week n Communications and notifications § Notify the administrator about repeated login failures n Workflow triggering § such as (partly) manual registration procedures i. e. Policies may specify actions n To be interleaved with the decision process Daniel Olmedilla PUC Seminar 2007 Aug. 21 st, 2007 17

Integration of Actions Example allow(rent(Car, Type)) ← Provisional Action: send a driving_license(DL), notification DL. age > 18, check_availability(Car, Office), notify(“New Reservation”, Car, Type, Office). check_availability(Car, Office) ← Package Action: in(available(Car, Office), database access rdbms: query( Who performs it? “SELECT car, office FROM Available_Cars WHERE Type = ” & Type, “car_database”) ). Action notify(_, _, _, _)->actor: self. definition notify(Subject, Car, Type, Office)->action: “http: //…/#e-mail” Daniel Olmedilla PUC Seminar 2007 Aug. 21 st, 2007 18

Integration of Actions Evidence allow(rent(Car, Type)) ← credential (DL), DL. type: driving_license, DL. age > 18, Implies that the requester discloses an evidence available(Car, Type). credential(C)->type: provisional. credential(C)->actor: peer. The actor in this case is the requester Daniel Olmedilla PUC Seminar 2007 Aug. 21 st, 2007 19

Integration of Actions Strong, Soft, and Lightweight Evidence How can individuals prove their eligibility? n Strong evidence (credentials) § e. g. digital credentials (id, credit cards, subscriptions) n Soft evidence § e. g. numerical reputation measures § PGP, e. Bay, . . . n Lightweight evidence (declarations) § e. g. “accept buttons” (copyright/license agreements) § e. g. “web forms” (authentication, registration) They should be integrated for balancing: § § Daniel Olmedilla trust level E. g. micropayments risk level vs. buying plane tickets computational costs usability (fetching credentials, personal assistants) PUC Seminar 2007 Aug. 21 st, 2007 20

Outline n Introduction n Policy Specification n Integration of Actions § Legacy Systems § Evidences n Negotiations § Filtering n Cooperativeness & Verbalization n Conclusions & Further Work Daniel Olmedilla PUC Seminar 2007 Aug. 21 st, 2007 21

Negotiations Access Control in open systems (I) Daniel Olmedilla PUC Seminar 2007 Aug. 21 st, 2007 22

Negotiations Access Control in open systems (II) Assumption: I already know you n you have a local account! Not a member? Daniel Olmedilla PUC Seminar 2007 Aug. 21 st, 2007 23

Negotiations Scalability and usability issues In the absence of more flexible methods n Web services have to keep accounts for all customers § Possibly >1 for some customers § Some accounts are used very few times n Users have to create accounts all the time § Many passwords vs. reuse (highly vulnerable) § Needs automated password management n Articulated business policies are discouraged § Because they would require continuous user intervention Daniel Olmedilla PUC Seminar 2007 Aug. 21 st, 2007 24

Negotiations Privacy issues n Credentials may be sensitive § Credit card numbers, SSN, . . . n Servers cannot be trusted, in general § New services, unknown responsibles, . . . n Credential release may be subject to server certifications n Seal programs (self regulation): agree to § Follow precise practices for protecting information § Be subject to audit procedures § TRUSTe, BBBOn. Line, Web. Trust n Seal program membership can be certified with electronic credentials Daniel Olmedilla PUC Seminar 2007 Aug. 21 st, 2007 25

Negotiations Bilateral and iterative process Alice Bob Step 1: Alice requests a service from Amazon Step 2: Amazon discloses its policy for the service Step 3: Alice discloses her policy for VISA Step 4: Amazon discloses its BBB credential Step 5: Alice discloses her VISA card credential Service Step 6: Amazon grants access to the service [Winsborough, Seamons, Jones. Automated trust negotiation. DARPA Information Survivability Conference and Exposition, IEEE Press, Jan 2000 ] Daniel Olmedilla PUC Seminar 2007 Aug. 21 st, 2007 26

Negotiations Characteristics n Every party can define policies to control outsiders’ use of its resources § Service access control (security) § Credential disclosure control (privacy) § Business rules n Decisions are based on parties’ properties n Properties are established iteratively and bilaterally by the disclosure of certificates and declarations, i. e. negotiations Daniel Olmedilla PUC Seminar 2007 Aug. 21 st, 2007 27

Negotiations How to formulate requests (I) One by one? n Slow § More messages (as opposed to one global request) n Bad w. r. t. privacy § Not known what the next request will be § Unnecessary disclosures § After submitting n credentials you realize you miss the next n Example § After submitting your id you realize your credit card is not accepted by the server Daniel Olmedilla PUC Seminar 2007 Aug. 21 st, 2007 28

Negotiations How to formulate requests (II) All alternatives at once? n Less messages (good!) n Combinatorial explosion: § one id and one credit card Daniel Olmedilla Passport + VISA Passport + Mastercard. . . Student card + VISA Student card + Mastercard. . . SSN + VISA SSN + Mastercard. . . PUC Seminar 2007 Aug. 21 st, 2007 29

Negotiations How to formulate requests (& III) Send the policy! n As a compact representation of all alternatives § To download paper XY. pdf do one of the following: 1) Submit an Amazon card 2) Submit a valid id an accepted credit card n The client can § Verify that the whole condition can be satisfied § Choose the best option § Minimizing the sensitivity of disclosed PUC Aug. 21 st, 2007 Daniel Olmedilla information Seminar 2007 30

Negotiations Protune Example Policy (I) allow(download(Resource)) ← public(Resource). allow(download(Resource)) ← authenticated(User), has. Subscription(User). Hard evidence Soft evidence authenticated(User) ← credential(C), C. type: ’id’. authenticated(User) ← declaration([ user=User, password=P ]), passwd(User, P). has. Subscription(‘Alice’). has. Subscription(‘John’). passwd(‘Alice’, ’$1234 ab 3’). passwd(‘John’, ‘ 8%%&ca’). Daniel Olmedilla PUC Seminar 2007 Private information Aug. 21 st, 2007 31

Negotiations Policy Filtering Alice Amazon allow(download(‘file 1234. pdf’)) ? allow(download(Resource)) ← public(Resource). ‘file 1234. pdf’ is not public blurred( ) Alice does not know what authenticated means blurred( authenticated(User) ← credential(C), C. type: ’id’. ) Only shared predicates Semantic Policy Information. Usable for explanations (see later) Daniel Olmedilla PUC Seminar 2007 allow(download(Resource)) ← authenticated(User), has. Subscription(User). authenticated(User) ← declaration([ user=User, password=P ]), passwd(User, P). has. Subscription(‘Alice’). has. Subscription(‘John’). passwd(‘Alice’, ’$1234 ab 3’). passwd(‘John’, ‘ 8%%&ca’). Aug. 21 st, 2007 32

Negotiations Protune filtering metapolicies allow(download(Resource)) ← public(Resource). allow(download(Resource)) ← authenticated(User), has. Subscription(User). authenticated(User) ← credential(C), C. type: ’id’. authenticated(User) ← declaration([ user=User, password=P ]), passwd(User, P). Daniel Olmedilla has. Subscription(‘Alice’). has. Subscription(‘John’). passwd(‘Alice’, ’$1234 ab 3’). passwd(‘John’, ‘ 8%%&ca’). passwd(User, Pwd)->sensitivity: private. has. Subscription(User)->sensitivity: private. PUC Seminar 2007 Aug. 21 st, 2007 33

Outline n Introduction n Policy Specification n Integration of Actions § Legacy Systems § Evidences n Negotiations § Filtering n Cooperativeness & Verbalization n Conclusions & Further Work Daniel Olmedilla PUC Seminar 2007 Aug. 21 st, 2007 34

Cooperativeness & Verbalization User Lacks n Lack of awareness § Users ignore the policies applied by the systems they use n Lack of control § Users don't know how to personalize their policies n Lack of technical competence Daniel Olmedilla PUC Seminar 2007 Aug. 21 st, 2007 35

Cooperativeness & Verbalization Widespread security A recent experiment: n Several computers connected to the network § Different platforms and configurations n With default policies: intrusion in <5 min. § Bias towards functionality n With personalized policies: safe for 2 weeks § Till the end of the experiment [Avantgarde. http: //www. avantgarde. com/xxxxttln. pdf ] Daniel Olmedilla PUC Seminar 2007 Aug. 21 st, 2007 36

Cooperativeness & Verbalization User awareness and control n Explain policies and system decisions § Make rules & reasoning intelligible to the common user n Encourage people to personalize their policies § Make it easy for users to write their own rules n Use natural language? § “Academic users can download the files in folder historical_data whenever their creation date precedes 1942” § Suitably restricted to avoid ambiguities § Fortunately, users spontaneously formulate rules Daniel Olmedilla PUC Seminar 2007 Aug. 21 st, 2007 37

Cooperativeness & Verbalization Cooperative policy enforcement Crucial for the success of a web service § Never say (only) “no”! § Encourage first-time users § Who don't know how to use your service n Explain policy decisions You can't open this door, but you § Especially failures can ask Alice for permission § Advanced queries: Why not n Guide users § Advanced queries: How-to, What-if Daniel Olmedilla PUC Seminar 2007 Aug. 21 st, 2007 38

Cooperativeness & Verbalization Motivation Suppose Alice's request is rejected She may want to ask questions like: n Why didn't you accept my credit card? Other possible queries n How-to queries n What-if queries § Would I get the special discount on financial products X if I were locally employed? Daniel Olmedilla PUC Seminar 2007 Aug. 21 st, 2007 39

Why-not demo Sample screenshot Daniel Olmedilla PUC Seminar 2007 Aug. 21 st, 2007 40

Why-not demo Sample screenshot Daniel Olmedilla PUC Seminar 2007 Aug. 21 st, 2007 41

Why-not demo After one more step. . . Daniel Olmedilla PUC Seminar 2007 Aug. 21 st, 2007 42

Cooperativeness & Verbalization Why-Not Queries FILTERED POLICY [r 3]: allow(download(Resource)) ← authenticated(User), blurred( has. Subscription(User) ). I CAN’T PROVE THAT it is allowed to download paper 14. pdf BECAUSE Rule [r 3] is not applicable: THERE IS NO User SUCH THAT User is authenticated [r 4]: allow(download(Resource) ← authenticated(User), paid(User, Resource). [details] AND Rule [r 4] is not applicable: THERE IS NO User SUCH THAT User is authenticated [details] MOREOVER THERE IS NO User SUCH THAT User has paid for paper 14. pdf [details] METAPOLICY allow(download(Resource)). explanation: “It is allowed to download “ & Resource. public(Resource). explanation: Resource & “ is public”. authenticated(User). explanation: User & “ is authenticated”. has. Subscription(User). explanation: User & “ has subscription”. paid(User, Resource). explanation: User & “ has paid for “ & Resource. [ Bonatti, Olmedilla, Peer. Advance policy explanations on the web. ECAI 2006, pages 200 -204, Riva del Garda, Italy, Aug-Sep 2006. IOS Press. ] Daniel Olmedilla PUC Seminar 2007 Aug. 21 st, 2007 43

Cooperativeness & Verbalization Why-Not Queries: pruned or full “authenticated” depends on a credential. “has. Subscription” depends on “authenticated” I CAN’T PROVE THAT it is allowed to download paper 14. pdf BECAUSE Rule [r 3] is not applicable: THERE IS NO User SUCH THAT User is authenticated AND [r 4]: allow(download(Resource) ← authenticated(User), paid(User, Resource). [details] Pruning: User is not authenticated so it makes no sense to inspect her subscriptions Rule [r 4] is not applicable: THERE IS NO User SUCH THAT User is authenticated [details] MOREOVER THERE IS NO User SUCH THAT User has paid for paper 14. pdf [details] Daniel Olmedilla PUC Seminar 2007 FILTERED POLICY [r 3]: allow(download(Resource)) ← authenticated(User), blurred( has. Subscription(User) ). METAPOLICY allow(download(Resource)). explanation: “It is allowed to download “ & Resource. public(Resource). explanation: Resource & “ is public”. authenticated(User). explanation: User & “ is authenticated”. has. Subscription(User). explanation: User & “ has subscription”. paid(User, Resource). explanation: User & “ has paid for “ & Resource. Aug. 21 st, 2007 44

Outline n Introduction n Policy Specification n Integration of Actions § Legacy Systems § Evidences n Negotiations § Filtering n Cooperativeness & Verbalization n Conclusions & Further Work Daniel Olmedilla PUC Seminar 2007 Aug. 21 st, 2007 45

Conclusions & Further Work Summary Protune is a framework where n Behavior is flexible § Can be changed/updated - without re-coding, re-compiling, re-installing, etc… - In a costless manner n Covers as many different policies as possible n Policies are rule based n Allows for semantic and privacy aware negotiations § No previous shared knowledge required n Produce verbalizations in order to increase user understanding Daniel Olmedilla PUC Seminar 2007 Aug. 21 st, 2007 46

Conclusions & Further Work Implemented prototype n Prototype available (in alpha state) n Freely distributed n All in java § Easily configurable, multi-thread § Legacy systems integration: RDBMS, LDAP, RDF repositories, … Daniel Olmedilla PUC Seminar 2007 Aug. 21 st, 2007 47

Conclusions & Further Work n Natural language policy specification n Policy Engineering Tools § Specification § Validation § Visualization n Stable release n We search for new application scenarios and real policies !! Daniel Olmedilla PUC Seminar 2007 Aug. 21 st, 2007 48

Thanks! Questions? olmedilla@L 3 S. de - http: //www. L 3 S. de/~olmedilla/