You are here: Resources > FIDIS Deliverables > Privacy and legal-social content > D14.2: Study on Privacy in Business Processes by Identity Management > 
Case Study: Using Attributes as Access Rights in eGovernment  Title:
CASE STUDY: PRIVACY THREATS IN A LOYALTY PROGRAM
 Case-Study: Privacy Threats of Intelligent Software Agents

 

Case Study: Privacy Threats in a Loyalty Program

The attacker model focuses on privacy threats of customers which are at the same time security threats of the loyalty program provider. Merchants are seen as attackers on privacy. Their aim is to link customers’ transactions and thereby to create a profile by virtually combining their single, merchant-dependent profiles. Figure 4.3 shows the privacy problem when using a loyalty card for getting premium points. Figure 4.4 shows the privacy problem when delegating an access right on a specific customer’s profile. 


Figure 4. Linking customer’s profiles by merchants when buying goods or services with a loyalty card.

 Merchants are able to link their profiles by the unique card number (Card ID) of customer’s loyalty card. It follows that they know what this customer has bought at the supermarket, the pharmacy, and the insurance company.

Privacy as informational self-determination is violated: the customer is not able to determine the disclosure of personal data. By linking profiles, customer’s data are disclosed to other merchants and used for other purposes than those of the collection, since his profiles are now used by other merchants, too. Additionally, linking profiles is not an interest of the loyalty program provider. The collection of these profiles at his database empowers the loyalty program provider to analyze customers’ profiles and to offer queries for marketing purposes. If the merchants are able to link their profiles without the loyalty program provider, the collection of profiles is worthless for the loyalty program provider. A merchant would not pose such a query at the loyalty program provider anymore. 

If a customer delegates an access right on his profile to a merchant, he has two options for delegation: 

  1. The customer issues a delegation credential for the merchant, e.g. a X.509 Proxy Certificate (Von Welch, Foster, Kesselmann, Mulmo, Pearlman, Tuecke, Gawor, Medder and Siebenlist, 2004). 

  2. A CA issues a delegation credential for the merchant on behalf of the customer, e.g. a SPKI certificate (Ellison, Frantz, Lampson, Rivest, Thomas and Ylonen, 1999) or a Kerberos proxiable ticket granting ticket (Kohl and Neuman, 1993). 

In both cases, transactions of a customer are linkable by every merchant and, in the second case, also by the CA. In the first case, the digital signature of the customer for his delegation credential makes him traceable. In the second case, the identifier of a customer is fixed in a credential and obvious for every participating service provider. Figure 4.4 shows the profiling possibility for the second case, if Kerberos is applied. 


Figure 4. Linking customer’s profile if Kerberos is applied for delegation of rights.

 

Case Study: Using Attributes as Access Rights in eGovernment  fidis_wp14_d14.2-study_on_privacy_in_business_processes_by_identity_management-v09_02.sxw  Case-Study: Privacy Threats of Intelligent Software Agents
18 / 38