A Semantic based Privacy Framework for Web Services

1
A Semantic based Privacy Framework for Web
Services

• Arif Tumer, Asuman Dogac, Hakki Toroslu
• Middle East Technical University
• Ankara Turkey

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

3
An Example Class Hierarchy for Travel Domain With
User Preferences
DAML-S
Service
TravelService
Transportation
Accommodation
Entertainment
AirTransportation
LandTransfer
SeaTransfer
Reserve
BuyTicket
4
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

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
6
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
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
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
Conditional Statements

• ltpriIfRulegt
• ltpriIf rdfparseType"Resource"gt
• ltpriNotGiven rdfresource"...emailAddress"/
  gt
• lt/priIfgt
• ltpriThen rdfparseType"Resource"gt
• ltpriMandatory rdfresource"...postalAddress
  "/gt
• lt/priThengt
• lt/priIfRulegt
• ltpriIfRulegt
• ltpriIf rdfparseType"Resource"gt
• ltpriNotGiven rdfresource"...creditCardNo"/
  gt
• lt/priIfgt
• ltpriThen rdfparseType"Resource"gt
• ltpriMandatory rdfresource"...bankAccountNo
  "/gt
• lt/priThengt
• lt/priIfRulegt

10
Describing Users Privacy Preferences

• Describe the permission levels for Users 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
An Example Class Hierarchy for Travel Domain With
User Preferences
DAML-S
Service
Free Home.Phone Limited Age
Free Name NotGiven Mobile.Phone
Limited EmailAddress
TravelService
Transportation
Accommodation
Entertainment
AirTransportation
LandTransfer
SeaTransfer
Reserve
BuyTicket
Free CreditCardNo
12
Describing Users Privacy Preferences (Contd)

• 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
An Example Set of Privacy Rules

• ltpriRulegt
• ltpriRole rdfresource".../TravelService"/gt
• ltpriData rdfparseType"Resource"gt
• ltpriLimited rdfresource"...Age"/gt
• ltpriFree rdfresource"...Home.Phone"/gt
• lt/priDatagt
• lt/priRulegt
• ltpriRulegt
• ltpriRole rdfresource".../TransportationService
  "/gt
• ltpriData rdfparseType"Resource"gt
• ltpriNotGiven rdfresource"...CreditCardNo"/gt
• ltpriNotGiven rdfresource"...Mobile.Phone"/gt
• ltpriLimited rdfresource"...EmailAddress"/gt
• ltpriFree rdfresource"...Name"/gt
• lt/priDatagt
• lt/priRulegt

14
General Architecture
Context Server
Service Registry

• Privacy Preferences of a user associated with
  nodes in a service ontology
• Users Context Data

• Service Ontology
• Input Parameters of a services as mandatory or
  optional elements as well as conditional request
  statements

User Agent
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

16
Rule Extraction Process (Contd)

• At each service node, only privacy rules
  requested by the child nodes are extracted
• Atomic permission levels are collected at the
  services node at the end of 2nd Phase

17
Negotiation Process

• Comparison of services input parameters and
  their necessities with users 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
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
An Example Scenario (Contd)

• Users 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
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 users privacy
  preferences

DAML-S
Service
TravelService
Transportation
AirTransportation
BuyTicket
21
Example Rule Extraction Phase 1
DAML-S
Service
TravelService
Transportation
AirTransportation
Needs Name, Mobile.Phone, Home.Phone,
EmailAddress, Age Free CreditCardNo
BuyTicket
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
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
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
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
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
27
Example Negotiation

• Users 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
Example Negotiation (Contd)

• 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
The Advantages of the Proposed Approach

• Less effort from users side
• The privacy preferences are declared for a group
  of services (less effort from users 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
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
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
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
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
Thank you for your attention!