1. I.H. TorosluESSW Workshop Budapest May 20, 20031 A Semantic based Privacy Framework for Web Services Arif Tumer, Asuman Dogac, Hakki Toroslu Middle East Technical University Ankara Turkey

2. I.H. Toroslu ESSW Workshop Budapest May 20, 2003 2/32 The aim Exploiting semantics for protecting user's privacy when accessing the Web services The proposed framework  Allows Web services to declare their input parameters as Mandatory or Optional  Allows users declare their privacy preferences as Free, Limited, or NotGiven on the basis of a domain specific service ontology  Aim: To provide an agreement that suitable to both parties

3. I.H. Toroslu ESSW Workshop Budapest May 20, 2003 3/32 An Example Class Hierarchy for Travel Domain With User Preferences DAML-S Service TravelService Transportation AccommodationEntertainment AirTransportationLandTransferSeaTransfer Reserve BuyTicket

4. I.H. Toroslu ESSW Workshop Budapest May 20, 2003 4/32 Specifying Data Requests of Web Services An Example: Transportion Web Service Input Parameters: (Name, Mobile.Phone, Home.Phone, EmailAddress, Age) These properties are defined as the sub property of DAML-S inputParameter MandatoryOptional

5. I.H. Toroslu ESSW Workshop Budapest May 20, 2003 5/32 Specifying Data Requests of Web Services An Example: Transportation Service Input Parameters (Name, Mobile.Phone, Home.Phone, EmailAddress, Age) Conditional Rule: If Mandatory Mobile.Phone number is not given then EmailAddress is Mandatory MandatoryOptional

6. I.H. Toroslu ESSW Workshop Budapest May 20, 2003 6/32 Specifying Data Requests of Web Services 1. The input parameters of the service 2. The declaration of how essential the input parameter is for the service to execute (mandatory, optional) 3. The rules requesting alternate data elements if a mandatory piece of information is not provided by the user

7. I.H. Toroslu ESSW Workshop Budapest May 20, 2003 7/32 Specifying Data Requests of Web Services Associate necessity levels on input parameters of Web services  Mandatory: Input element is crucial for the service  Optional: Non-existence of the element does not hinder the enactment of the service

8. I.H. Toroslu ESSW Workshop Budapest May 20, 2003 8/32 Conditional Statements Alternatives handled via Conditional Statements  Describe alternative input parameters with associated necessities anticipating that a crucial element may not be released by the user (e.g., mobile phone number)  Condition: List of Mandatory elements  Action: Set of new/altered input parameters that may be introduced when the elements in the Condition are not released

9. I.H. Toroslu ESSW Workshop Budapest May 20, 2003 9/32 Conditional Statements

10. I.H. Toroslu ESSW Workshop Budapest May 20, 2003 10/32 Describing User’s Privacy Preferences Describe the permission levels for User’s Context Data Defined in Two Dimensions  Context Ontology  Service Ontologies Basic Properties:  Permission definitions associated with a service node is applicable to all service nodes below this node in the service ontology  Specialized definitions override general ones

11. I.H. Toroslu ESSW Workshop Budapest May 20, 2003 11/32 An Example Class Hierarchy for Travel Domain With User Preferences DAML-S Service TravelService Transportation AccommodationEntertainment AirTransportationLandTransferSeaTransfer Reserve BuyTicket Free = { CreditCardNo } Free = { Name } NotGiven = { Mobile.Phone } Limited = { EmailAddress } Free = { Home.Phone } Limited = { Age }

12. I.H. Toroslu ESSW Workshop Budapest May 20, 2003 12/32 Describing User’s Privacy Preferences (Cont’d) Collection of Privacy Rule Set associated with nodes in the service ontology Associated permissions with context ontology on various levels Provide different permission levels  Free: Element is provided  NotGiven: Element is not released  Limited: Element is provided if only it is mandatory for service enactment

13. I.H. Toroslu ESSW Workshop Budapest May 20, 2003 13/32 An Example Set of Privacy Rules

14. I.H. Toroslu ESSW Workshop Budapest May 20, 2003 14/32 General Architecture Privacy Preferences of a user associated with nodes in a service ontology User’s Context Data Context Server Service Ontology Input Parameters of a services as mandatory or optional elements as well as conditional request statements Service Registry User Agent

15. I.H. Toroslu ESSW Workshop Budapest May 20, 2003 15/32 Rule Extraction Process Determine permission levels for input parameters of a service based on the service node Steps in Rule Extraction  Generation of Temporary Service Graph  1 st Phase – Upwards Traversal At each node, extract rules related with the input parameters Request the rules from parent service nodes for undetermined data elements  2 nd Phase – Downwards Traversal For each element with undetermined permission, receive rule from parents Determine the final rule based on permission level priority Push rules downwards in the hierarchy

16. I.H. Toroslu ESSW Workshop Budapest May 20, 2003 16/32 Rule Extraction Process (Cont’d) At each service node, only privacy rules requested by the child nodes are extracted Atomic permission levels are collected at the service’s node at the end of 2 nd Phase

17. I.H. Toroslu ESSW Workshop Budapest May 20, 2003 17/32 Negotiation Process Comparison of service’s input parameters and their necessities with user’s privacy preferences Aim: To provide an agreement that complies with both parties Basic Properties:  Mandatory elements must be released by the user  Optional elements are included if released freely  Conditional Statements may provide alternative requests when a mandatory element is not provided Release mandatory necessity on the element Introduce new requests (alternative input parameters)

18. I.H. Toroslu ESSW Workshop Budapest May 20, 2003 18/32 An Example Scenario Interaction with a service of “BuyTicket” node type Mandatory input parameters: Name, Mobile.Phone, CreditCardNo Optional input parameters: Age, EmailAddress Alternatively, if the user provides her email address (mandatory) and home number (optional), she does not need to release her mobile number

19. I.H. Toroslu ESSW Workshop Budapest May 20, 2003 19/32 An Example Scenario (Cont’d) User’s Privacy Preferences  For BuyTicket service node: CreditCardNo is provided Freely  For Transportation service node: Mobile.Phone and CreditCardNo are NotGiven EmailAddress is provided Limitedly Name released Freely  For Travel service node: Age is given in a Limited fashion Home.Phone is Free

20. I.H. Toroslu ESSW Workshop Budapest May 20, 2003 20/32 Example: Temporary Service Graph DAML-S Service TravelService Transportation AirTransportation BuyTicket Generation of this graph is initiated with the node of the interacting service, BuyTicket Presents the nodes of which, the associated rules will be process to extract user’s privacy preferences

21. I.H. Toroslu ESSW Workshop Budapest May 20, 2003 21/32 Example: Rule Extraction – Phase 1 DAML-S Service TravelService Transportation AirTransportation BuyTicket Needs = { Name, Mobile.Phone, Home.Phone, EmailAddress, Age } Free = { CreditCardNo }

22. I.H. Toroslu ESSW Workshop Budapest May 20, 2003 22/32 Example: Rule Extraction – Phase 1 DAML-S Service TravelService Transportation AirTransportation BuyTicket Needs = { Name, Mobile.Phone, Home.Phone, EmailAddress, Age } Free = { CreditCardNo } Needs = { Home.Phone, Age } Free = { Name } NotGiven = { Mobile.Phone } Limited = { EmailAddress }

23. I.H. Toroslu ESSW Workshop Budapest May 20, 2003 23/32 Example: Rule Extraction – Phase 1 DAML-S Service TravelService Transportation AirTransportation BuyTicket Needs = { Name, Mobile.Phone, Home.Phone, EmailAddress, Age } Free = { CreditCardNo } Needs = { Home.Phone, Age } Free = { Name } NotGiven = { Mobile.Phone } Limited = { EmailAddress } Needs = { } Free = { Home.Phone } Limited = { Age }

24. I.H. Toroslu ESSW Workshop Budapest May 20, 2003 24/32 Example: Rule Extraction – Phase 2 DAML-S Service TravelService Transportation AirTransportation BuyTicket Needs = { Name, Mobile.Phone, Home.Phone, EmailAddress, Age } Free = { CreditCardNo } Needs = { Home.Phone, Age } Free = { Name } NotGiven = { Mobile.Phone } Limited = { EmailAddress } Free = { Home.Phone } Limited = { Age }

25. I.H. Toroslu ESSW Workshop Budapest May 20, 2003 25/32 Example: Rule Extraction – Phase 2 DAML-S Service TravelService Transportation AirTransportation BuyTicket Needs = { Name, Mobile.Phone, Home.Phone, EmailAddress, Age } Free = { CreditCardNo } Free = { Name, Home.Phone } NotGiven = { Mobile.Phone } Limited = { EmailAddress, Age } Free = { Home.Phone } Limited = { Age }

26. I.H. Toroslu ESSW Workshop Budapest May 20, 2003 26/32 Example: Rule Extraction – Phase 2 DAML-S Service TravelService Transportation AirTransportation BuyTicket Free = { CreditCardNo, Name, Home.Phone } NotGiven = { Mobile.Phone } Limited = { EmailAddress, Age } Free = { Name, Home.Phone } NotGiven = { Mobile.Phone } Limited = { EmailAddress, Age } Free = { Home.Phone } Limited = { Age }

27. I.H. Toroslu ESSW Workshop Budapest May 20, 2003 27/32 Example: Negotiation User’s Privacy Preferences based on the service node  Free = { Name, Home.Phone, CreditCardNo }  Limited = { Age, EmailAddress }  NotGiven = { Mobile.Phone } Mandatory input parameter Mobile.Phone is not provided hence conditional statement is triggered. Alternative input parameters are introduced. Finalized input parameters  Mandatory = { Name, CreditCardNo, EmailAddress }  Optional = { Age, Home.Phone }

28. I.H. Toroslu ESSW Workshop Budapest May 20, 2003 28/32 Example: Negotiation (Cont’d) The input parameters included in the agreement  Mandatory elements that are provided Freely or Limitedly  Optional elements that are provided Freely Result of Negotiation  Mandatory = { Name, CreditCardNo, EmailAddress }  Optional = { Home.Phone } Age is removed as it is provided in a Limited fashion

29. I.H. Toroslu ESSW Workshop Budapest May 20, 2003 29/32 The Advantages of the Proposed Approach Less effort from user’s side:  The privacy preferences are declared for a group of services (less effort from user’s side)  A user may declare the same policy for several different service groups  The privacy preferences at the upper level classes are inherited by lower level service classes Flexibility  Web services declare alternate data requests if a mandatory input is not given by the user Interoperability  Declaring the user preferences based on a standard service ontology like DAML-S helps with the interoperability problem

30. I.H. Toroslu ESSW Workshop Budapest May 20, 2003 30/32 Future Work Web services need to know more than user preferences A “user context” that includes any information that can be used to characterize the user and her situation Hence user context should include user's local data obtained through sensors As well as any data stored about the user such as those stored in Customer Relationship Management (CRM) systems to make effective use of Web services

31. I.H. Toroslu ESSW Workshop Budapest May 20, 2003 31/32 Future Work This context information should be available to any authorized agent at any time, any where in a secure manner This necessitates developing globally accessible, secure “context servers” However, some of the data can be distributed over several heterogeneous repositories Since these devices accept input in different mark up languages; the context server needs to recognize the device and provide the information in the format that can be accepted by the device

32. I.H. Toroslu ESSW Workshop Budapest May 20, 2003 32/32 Future Work User context should be available in a format that is machine processable and interoperable. In this respect developing a user context ontology is essential

33. I.H. Toroslu ESSW Workshop Budapest May 20, 2003 33/32 Future Work Yet all this will make privacy a graver concern for users There is a need for trusted authorities for delivering user context to authorized requestors in a secure manner

34. I.H. Toroslu ESSW Workshop Budapest May 20, 2003 34/32 Thank you for your attention!