1 / 34

A Semantic based Privacy Framework for Web Services

A Semantic based Privacy Framework for Web Services. Arif Tumer, Asuman Dogac, Hakki Toroslu Middle East Technical University Ankara Turkey. The aim. Exploiting semantics for protecting user's privacy when accessing the Web services The proposed framework

nishi
Download Presentation

A Semantic based Privacy Framework for Web Services

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  2. 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 ESSW Workshop Budapest May 20, 2003

  3. An Example Class Hierarchy for Travel Domain With User Preferences DAML-S Service TravelService Transportation Accommodation Entertainment AirTransportation LandTransfer SeaTransfer Reserve BuyTicket ESSW Workshop Budapest May 20, 2003

  4. Mandatory Optional 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 ESSW Workshop Budapest May 20, 2003

  5. 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 Mandatory Optional ESSW Workshop Budapest May 20, 2003

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

  7. 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 ESSW Workshop Budapest May 20, 2003

  8. 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 ESSW Workshop Budapest May 20, 2003

  9. Conditional Statements <pri:IfRule> <pri:If rdf:parseType="Resource"> <pri:NotGiven rdf:resource="...#emailAddress"/> </pri:If> <pri:Then rdf:parseType="Resource"> <pri:Mandatory rdf:resource="...#postalAddress"/> </pri:Then> </pri:IfRule> <pri:IfRule> <pri:If rdf:parseType="Resource"> <pri:NotGiven rdf:resource="...#creditCardNo"/> </pri:If> <pri:Then rdf:parseType="Resource"> <pri:Mandatory rdf:resource="...#bankAccountNo"/> </pri:Then> </pri:IfRule> ESSW Workshop Budapest May 20, 2003

  10. 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 ESSW Workshop Budapest May 20, 2003

  11. An Example Class Hierarchy for Travel Domain With User Preferences DAML-S Free = { Home.Phone } Limited = { Age } Service Free = { Name } NotGiven = { Mobile.Phone } Limited = { EmailAddress } TravelService Transportation Accommodation Entertainment AirTransportation LandTransfer SeaTransfer Reserve BuyTicket Free = { CreditCardNo } ESSW Workshop Budapest May 20, 2003

  12. 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 ESSW Workshop Budapest May 20, 2003

  13. An Example Set of Privacy Rules <pri:Rule> <pri:Role rdf:resource=".../TravelService"/> <pri:Data rdf:parseType="Resource"> <pri:Limited rdf:resource="...#Age"/> <pri:Free rdf:resource="...#Home.Phone"/> </pri:Data> </pri:Rule> <pri:Rule> <pri:Role rdf:resource=".../TransportationService"/> <pri:Data rdf:parseType="Resource"> <pri:NotGiven rdf:resource="...#CreditCardNo"/> <pri:NotGiven rdf:resource="...#Mobile.Phone"/> <pri:Limited rdf:resource="...#EmailAddress"/> <pri:Free rdf:resource="...#Name"/> </pri:Data> </pri:Rule> ESSW Workshop Budapest May 20, 2003

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

  15. 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 • 1st Phase – Upwards Traversal • At each node, extract rules related with the input parameters • Request the rules from parent service nodes for undetermined data elements • 2nd 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 ESSW Workshop Budapest May 20, 2003

  16. 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 2nd Phase ESSW Workshop Budapest May 20, 2003

  17. 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) ESSW Workshop Budapest May 20, 2003

  18. 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 ESSW Workshop Budapest May 20, 2003

  19. 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 ESSW Workshop Budapest May 20, 2003

  20. Example: Temporary Service Graph • 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 DAML-S Service TravelService Transportation AirTransportation BuyTicket ESSW Workshop Budapest May 20, 2003

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

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

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

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

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

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

  27. 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 } ESSW Workshop Budapest May 20, 2003

  28. 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 ESSW Workshop Budapest May 20, 2003

  29. 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 ESSW Workshop Budapest May 20, 2003

  30. 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 ESSW Workshop Budapest May 20, 2003

  31. 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 ESSW Workshop Budapest May 20, 2003

  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 ESSW Workshop Budapest May 20, 2003

  33. 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 ESSW Workshop Budapest May 20, 2003

  34. Thank you for your attention! ESSW Workshop Budapest May 20, 2003

More Related