D.1.2 Report on requirements study II

Transcription

1 D.1.2 Report on requirements study II Faysal Boukayoua, Italo Dacosta (editor), Koen Decroix, Bart De Decker (editor), Jorn Lapon, Luc Martens, Milica Milutinovic (editor), Vincent Naessens, Bart Preneel, Andreas Put (editor), Stefaan Seys, Dave Singelee, Kris Vanhecke, Jan Vossaert April 2013

2

3 Contents 1 Introduction 1 2 Basic Loyalty Scenario Introduction Privacy-friendly Virtual Loyalty System (PVLS) architecture PVLS Client Application PVLS Server Application System Properties PVLS benefits Benefits to customers Benefits to providers Loyalty Protocols Customer registration Collecting loyalty points Using loyalty points Use Case Stakeholders Assumptions Threat model Research challenges Requirements Family loyalty card Introduction Use Case Stakeholders Assumptions Scenarios Threat model Benefits Research challenges Requirements Brand loyalty Introduction Use Case Stakeholders Assumptions Scenarios i

4 4.2.4 Threat model Benefits Research challenges Requirements Providers collaboration Introduction Use Case Stakeholders Assumptions Scenarios Threat model Benefits Research challenges Requirements Personal Shopping Assistant Introduction Use Case Stakeholders Assumptions Scenarios Threat model Benefits Research challenges Requirements Vouchers Introduction Use Case Stakeholders Assumptions Scenarios Threat model Benefits Research challenges Requirements Conclusions 37 Acronyms 41 ii

5 Chapter 1 Introduction The increasing importance of customer loyalty has resulted in a widespread adoption of Customer Loyalty Programs (CLPs) by most providers (e.g., retailers, airlines, etc.). CLPs main goal is to to retain existing customers and attract new ones. Customers enrolled in a CLP receive different incentives (e.g., loyalty points, discount vouchers, gifts, etc.) on each transaction with the retailer. During registration, customers provide personal information (e.g., name, address, age, etc.) and receive a loyalty card. The loyalty card is typically a plastic or paper-based card with an encoded number that uniquely identifies each customer (i.e., customer ID). On each transaction, customers should present their loyalty card to receive additional benefits. For example, customers can collect loyalty points that can later be exchanged for discounts or promotional items. CLPs allow providers not only to encourage loyalty behaviour but also to collect and analyze data about customers (e.g., purchasing habits, brand preferences, average spending, etc.). This information is useful to providers for planning better marketing and advertisement strategies. Unfortunately, existing CLPs have several shortcomings that hinder their complete adoption. First, CLPs data collection practices raise privacy concerns among customers. For instance, a recent survey [6] shows that nearly 30% of the participants think that CLPs require too much personal information and 24% cited that privacy concerns are the reason why they do not enroll in such programs. These privacy concerns have given CLPs a negative reputation [5, 9, 12]. Second, physical loyalty cards and tokens can be inconvenient for customers. For example, given the popularity of CLPs among providers, customers are forced to carry multiple loyalty cards or tokens in their wallets and keychains. Moreover, these cards and tokens can be easily lost or misplaced. In such situations, customers could lose part or all of their loyalty benefits. Finally, loyalty cards are not extensible, they just act as a read-only storage of the customer identification number. Hence, they are not suitable for more advanced services. In the last couple of years, the use of mobile devices such as smartphones have been proposed to fix some of the limitations of current CLPs. Due to their increasing popularity and multiple capabilities, smartphones are an attractive alternative to consolidate and replace physical loyalty cards. This approach is transparent for customers as most of them already carry smartphones everyday and are familiar with mobile applications. There are many mobile applications already available to consolidate both physical and digital loyalty cards as well as coupons and vouchers [1, 8,10,11]. Smartphones allow not only the consolidation of loyalty cards, coupons and vouchers, but also more advanced services. For instance, Belgacom and BNP Paribas Fortis recently announced the Belgian Mobile Wallet [2], a mobile application that in addition to loyalty cards also will support mobile identity management and payments. Still, none of these mobile-based approaches provide a solution for CLPs privacy issues. Therefore, it is desirable to design a solution that is both feature-rich and privacy-friendly for CLPs. In this report, we present the general design of our Privacy-friendly Virtual Loyalty System (PVLS), a smartphone-based loyalty system that provides customers with more control over their 1

6 information. With PVLS, customer transactions are anonymous and unlinkable by default; thus, reducing customers privacy concerns. Transactional data is stored and managed on the client-side, resulting in rich profiles controlled by customers. In addition, PVLS allows customers to selectively reveal information to providers. The integrity of the revealed information is protected by PVLS; therefore, the data collected by providers is not only less sensitive but also more accurate. PVLS design provides benefits to both customers and providers. For instance, customers could receive customized product recommendations based on their personal profiles without sacrificing privacy. Also, PVLS could be used to combine CLP from multiple providers; thus, facilitating cooperation. In addition, PVLS facilitates compliance with privacy laws because providers store less sensitive information about their customers. For more details about PVLS benefits, see Section 2.4. This report also extends and provides more detail to some of the loyalty scenarios and use cases presented in the D.1.1. Report on state-of-the-art and requirements study I report [4]. A total of five loyalty scenarios based on PVLS are presented. For each scenario, we provide a detailed description and both functional and non-functional (i.e., security and privacy) requirements. The report is organized as follows: Chapter 2 describes the basic PVLS architecture using a single-retailer scenario. It also presents the general benefits, properties, protocols, threat model and requirements of PVLS. These concepts apply to the more advanced scenarios presented in the following chapters. Chapter 3 presents a loyalty scenario where members of the same family are allowed to share loyalty points earned independently by each family member. Chapter 4 shows a loyalty scenario where brands can directly or indirectly (e.g., through retailers) measure and reward customer loyalty. Chapter 5 describes the details of a loyalty scenario where multiple providers collaborate and combine their loyalty programs. Chapter 6 presents a loyalty scenario where the PVLS mobile application is used to provide advanced shopping services to customers (e.g., product scanning, product recommendations or targeted advertisement). Chapter 7 describes how vouchers can be integrated into the PVLS architecture. Chapter 8 presents our concluding remarks and next steps. 2

7 Chapter 2 Basic Loyalty Scenario 2.1 Introduction In this Chapter we present the basic PVLS architecture using a single-provider loyalty scenario (Figure 2.1). Based on this scenario, we describe the general properties, benefits, threat model and requirements of a loyalty program based on PVLS. These concepts apply to the more advanced scenarios presented in later chapters. Most CLPs use physical loyalty cards to uniquely identify customers based on an identification number (i.e., customer ID). The customer ID is used to retrieve all the customers transaction and loyalty point information from the provider s database. In this model, the user has no control over the data stored by the provider. With PVLS, physical loyalty cards are replaced with a mobile application running on a smartphone (i.e., a virtual loyalty card). In addition, all the customer s transaction and loyalty points information is kept in storage controlled by the customer, not the provider. Moreover, by relying on anonymous credentials, PVLS allows customers to perform anonymous and unlinkable transactions as well as selective data disclosure. Based on these ideas, providers can use PVLS to implement privacy-friendly loyalty programs and more advanced customer services. 2.2 PVLS architecture PVLS follows a client-server architecture. Customers run the PVLS mobile application in their smartphones which interacts with the provider s server application (Figure 2.1). The client-server communication is wireless (i.e., WiFi, NFC) and protected using cryptographic mechanisms PVLS Client Application The PVLS client application is primarily designed to run on mobile devices such as smartphones. Smartphones are ideal for the PVLS client application due to their popularity, portability and processing and communication capabilities. However, the PVLS client application could also run on desktop computers to support certain operations (e.g., online shopping). The basic components of the PVLS client application are: Credential management. This component provides support for digital credential operations (e.g., request, storage, retrieval, authentication, claim and proof generations, etc.). Credentials are mainly used to authenticate users and proof loyalty point ownership. While anonymous credentials (e.g., Idemix and U-Prove) are the main target, this component could also support other type of credentials (e.g., X.509). 3

8 Figure 2.1: Basic PVLS architecture. Customers use the PVLS client application in their smartphones to communicate with the provider s PVLS server application to collect and spend loyalty points. Loyalty points management. This component provides support for all the loyalty points operations (e.g., collecting, storing, retrieving, spending, validating, viewing, expiring, etc.). Profile management. This component keeps track of all the customer s personal data and transaction information (e.g., time and date, products purchased, amount paid, etc.). This information can be partially revealed to the provider based on user policies defined by the customer. For example, a customer may reveal her age and some information about purchased products to obtain an additional discount or to get more personalized service. Persistent storage (DB). This component allows the application to store credentials, loyalty points and profile information locally in the smartphone or remotely (e.g., cloud storage). Most of this information should be protected using cryptographic mechanisms or secure hardware (e.g., secure element) PVLS Server Application The provider s back-end servers and Point-of-sale (POS) terminals run the PVLS server application. The PVLS server application consists of the following main components: Credential issuance and verification. Provides support for issuing credentials (e.g., loyalty credentials) to customers and verifying such credentials. In particular, it supports the verification of the different claims and proofs allowed by anonymous credentials. Credentials could be issued by the provider itself or by a third-party trusted by the provider. In the latter case, the provider only validates the credentials and their associated claims and proofs. Loyalty points issuance and verification. This component provides support for issuing loyalty points to customers after a transaction. In addition, it allows the provider to validate the points redeemed by customers. In particular, this component checks that the points are valid, have not been used before (i.e., double spending), have not expired and belong to the loyalty credential of the customer spending them. Persistent storage (DB). This component allows the provider to store customer registration information (e.g., name, address, etc.) obtained when customers register to use the 4

9 loyalty system. It also contains information that customers have agreed to reveal during transactions. In addition, it allows the provider to keep a log of used loyalty points to detect double-spending. Used loyalty points are removed from this log once they expire. 2.3 System Properties PVLS s design should provide the following properties: Customizable privacy. By default, transactions should not reveal any customer identifying information (i.e., anonymous transactions) and should not be linkable to prevent unauthorized profiling. However, customers should be able to selectively disclose information during a transaction or make certain transactions linkable. For instance, a customer may be willing to reveal her age in order to receive a discount or more personalized service. Trustworthiness. PVLS transactions are expected to be correct. Integrity and audit mechanisms should be in place to detect any deviations from the correct behaviour. In case of system failures, backup and recovery mechanisms should be in place to guarantee the continuity and integrity of the transactions. Security. PVLS should be robust against malicious behaviour from both customers and providers. For example, customers should not be able to forge loyalty points and providers should not be able to profile customers without their authorization. Malicious behaviour should be detected and penalized (i.e., customer s anonymity revocation). Usability. The PVLS client application should be easy to use for customers and should not negatively affect customer s shopping experience. In addition, the PVLS server application should be easy to configure and manage by the provider s employees. Flexibility. The proposed system should be able to support different scenarios without requiring significant modifications. For example, it should be compatible with different types of providers such as offline and online retailers, airlines, hotels and others. Extensibility. The proposed system should be easy to extend to support new functionality (e.g., vouchers, payments, product recommendations, etc.) and technologies (e.g., NFC, new sensors, etc.). Efficiency. The overhead introduced by PVLS operations should be small and it should not hinder the overall customer shopping experience and provider s operations. Deployability. PVLS should have reasonable hardware and software requirements for both customers and providers. For example, the PVLS client application should be able to run on lower-end smartphones. Similarly, the PVLS server application should be able to run on Commercial Off-The-Shelf (COTS) servers. Compatibility. PVLS should be compatible with existing CLPs. Moreover, PVLS should support an incremental deployment approach. For instance, customers that do not own a smartphone may still be able to participate in the loyalty program. Transparency. The proposed system should allow customers to view and audit all their information collected during the transactions with the provider. In addition, customers should be able to monitor what information has been revealed to different providers. 5

10 2.4 PVLS benefits Benefits to customers Better privacy guarantees. PVLS allows customers to take advantage of loyalty programs and other services without sacrificing privacy. By default, transactions do not reveal personally identifiable information to providers (i.e., anonymous transactions) and are independent of each other (i.e., unlinkable transactions). Still, customers can modify the anonymity level of their transactions by selectively disclosing information or linking certain transactions. Customer-controlled information. With PVLS, customers have improved control over their personally identifiable transactional data (e.g., shopping history, loyalty points). This data, typically stored in providers databases, is now stored and managed by customers. PVLS hides the complexities of this approach from the customers. Monetization of privacy. PVLS allows customer to build rich customer profiles based on personal, transactional and contextual information gathered by smartphones. This creates an opportunity for customers to partially reveal their profile information to providers in exchange for additional benefits (e.g., discount vouchers, loyalty points, etc.). Loyalty card dematerialization. With PVLS, customers do not need to carry multiple physical loyalty cards with them (a common nuisance). Instead, customers only need to carry their smartphones running the PVLS client application. This approach is straightforward for most customers as they already carry smartphones everywhere and are familiar with mobile applications. Enhanced customer experience. PVLS allows providers to implement not only loyalty programs but also other customer services such as targeted advertisement, product reviews and recommendations, vouchers and other. PVLS offers a common interface to these services and hides the complexities of underlying technologies. In addition, through a single mobile application, customers could access the services of not only one but multiple providers. Better protection of loyalty points. Compared with current CLPs, PVLS provides better security guarantees to customers credentials and loyalty information. For example, most loyalty cards and vouchers can be easily copied or stolen and misused by an adversary. Such attacks are significantly more difficult with PVLS Benefits to providers Competitive advantage due to better privacy practices. As stated in Chapter 1, many customers avoid loyalty programs due to privacy concerns [6, 7]. PVLS reduces such concerns by allowing providers to offer privacy-friendly loyalty programs where customers can control their profile information. Competitive advantage due to advanced services and technologies. PVLS s design allows providers to implement not only loyalty programs but also existing and new customer services using a common platform. In addition, new technologies can be added as they become available. Lower infrastructure costs. PVLS software stack does not require specialized hardware. At the provider s side, it can run on COTS servers. At the customer side, PVLS only requires a compatible smartphone. In addition, PVLS could replace and consolidate existing infrastructure. For example, in retailers scenarios, it could replace plastic loyalty card systems and custom shopping scanners. 6

11 Better quality, less sensitive data. By providing sufficient incentives, PVLS providers can collect information about customers and their shopping habits. In contrast with current practices, this approach is likely to produce more accurate and often more extensive (i.e., involving transactions with multiple providers) data because PVLS protects the integrity of the data revealed by customers. In addition, the data collected via PVLS will be mostly anonymous. Therefore, the provider will have less liability if this data is compromised. Moreover, it will be easier for the provider to comply with privacy regulations. Improved resilience against attacks. PVLS offers stronger security guarantees than current loyalty systems; therefore, fraud attempts are less likely to succeed. For example, illicitly sharing PVLS credentials and loyalty points could be prevented by binding them to the owner s smartphone or other credentials (e.g., BeID). 2.5 Loyalty Protocols A basic PVLS implementation should support three basic protocols: customer registration, collecting loyalty points and using loyalty points Customer registration Before customers can start collecting and using loyalty points, they need to register first with the provider s loyalty program. The registration could be done in person or online and it may require that customers formally proof their identities (e.g., showing their BeID or passport). During this step, customers need to install and configure the PVLS client application in their smartphones. After registration, a set of loyalty credentials will be issued by the provider (or a trusted thirdparty) to the customer and installed in the customer s smartphone Collecting loyalty points Registered customers can earn loyalty points every time they make a qualifying transaction or another activity defined by the provider. The exact amount, scope and validity of the loyalty points is determined by the provider s loyalty program policy. In general, the steps required from a customer to collect loyalty points during a visit to a retail store are: 1. At checkout, the customer uses her smartphone to start the PVLS client application. This application establishes a communication channel (e.g., NFC, WiFi, QR-codes) with the POS terminal. If required, the PVLS application could authenticate the POS terminal in this step. 2. The PVLS application proves to the POS terminal that the user is a customer based on the PVLS credentials in the smartphone. By default, this step does not reveal personally identifying information. The PVLS application also sends additional information required to generate the loyalty points. 3. Using the received data, the POS generates the loyalty points based on the customer purchase or action. The points are then sent to the PVLS application. 4. The PVLS application verifies the validity and correctness of the loyalty points received and stores them for later use. The application also shows the customer a summary of the transaction details Using loyalty points Collected loyalty points can be used to get discounts, special items and other benefits from the provider. In general, the customer decides when and how many points should be used during a 7

12 transaction. Customers should also be aware that loyalty points may expire. In general, providers have no idea of the amount of points a particular customer has; this data is stored by the PVLS application. Depending of the policy, providers should check that the points belong to the customer and that they have not been used before (i.e., double-spending). In general, the steps required by a customer to use loyalty points to get a discount during a visit to a retail store are: 1. At checkout, the customer uses her smartphone to start the PVLS client application. This application establishes a communication channel (e.g., NFC, WiFi, QR-codes) with the POS terminal. If required, the PVLS application could authenticate the POS terminal in this step. 2. The PVLS application proves to the POS terminal that the user is a customer based on the PVLS credentials in the smartphone. By default, this step does not reveal personally identifying information. The PVLS application also sends a request for information about the latest discounts available. 3. The POS terminal sends the information about the discounts available. Upon receiving it, the PVLS application shows it to the customer. Then, the customer selects the discount type and the required number of points. 4. The PVLS application sends the selected amount of loyalty points and the type of discount chosen to the POS terminal. 5. The POS terminal verifies the received points. It checks that they are valid and that have not been used before. For the latter, the provider requires mechanisms (e.g., audit log) to detect double-spending attempts. In addition, the terminal could verify that the points belong to the customer (i.e., if sharing points is not allowed). If the verification is successful, the discount is applied to the customer purchase. The terminal also notifies the PVLS application about the result of the operation. 6. The PVLS application validates the outcome of the discount operation and updates the total number of loyalty points stored (e,g., it deletes the used points). The application also logs the details of the operation and shows a summary to the customer. The user can also verify the discount applied in the final bill provided by the cashier. 2.6 Use Case In this section we describe the use case for the PVLS loyalty system scenario presented in Figure Stakeholders This use case has two stakeholders: A single provider (e.g., grocery store). Customers enrolled in the provider s loyalty program Assumptions This use case has the following assumptions: The provider has successfully implemented a loyalty program based on PVLS. Customers own a smartphone compatible with the PVLS client application. 8

13 The provider offers free Wi-Fi connectivity for customers that do not have a wireless data plan. The provider has defined a policy that dictates how loyalty points are collected and used. For example, the exchange rates between purchases and earned loyalty points, special temporary awards, etc. The provider s policy does not allow the sharing of credentials and loyalty points. In addition, loyalty points can only be used by the original owner Threat model. PVLS considers two adversaries: malicious customers that try to abuse or misuse the system and malicious providers that try to circumvent the PVLS security and privacy mechanisms to collect information and profile their customers. The threats due to these adversaries can negatively impact the trustworthiness, security and privacy properties of PVLS. The main threats to PVLS are: Credentials forging or modification. Malicious customers could try to forge new credentials or modify existing ones to impersonate other customers and/or to illegally obtain more benefits from the provider. For example, malicious customers could collude and modify their credentials to share loyalty points and associated benefits (e.g., loyalty status). Loyalty points forging or modification. Malicious customers could try to illicitly forge new loyalty points or increase the value of existing ones to obtain more benefits from the provider. Double-spending. Malicious customers could try to use loyalty points more than once to illegally obtain more benefits from the provider. Sharing loyalty points. Malicious customers could collude to illicitly share their earned points and obtain more benefits from the provider (assuming that the provider does not allow sharing loyalty points). In general, only the original customer that received the points should be able to use them. Sharing credentials. Malicious customers could try to share their credentials to illegally collect and use points. For example, malicious customers could collude to use the same credential to collect points faster. Credential and loyalty points theft. A malicious customer could try to steal the credential and/or loyalty points of other customers to impersonate them and use their points. In general, only the original customer that earned the points should be able to use them. Credential and loyalty points loss. Customers could lose access to their credentials temporarily or permanently. This could happen accidentally (e.g., lost smartphone, smartphone with low battery) or as a result of an attack (e.g., stolen smartphone, an adversary deletes a customer s credentials from their storage). As a result, customers may not be able to collect or use their loyalty points. Accidental data disclosure. Customer personal and transactional data could be disclosed to the provider and/or other parties accidentally. For example, the customer could misunderstand the consequences of a particular action or execute a particular command by accident (e.g., pressing the wrong button). Accidental data disclosure could also happen due to system failure or misconfiguration. Privacy attacks. Malicious providers (or other adversaries) could try to break the privacy protection offered by PVLS to obtain customers information. For example, a malicious provider could deceive customers into revealing information by using misleading user interfaces. 9

14 Side-channel information leaks. The anonymity and unlinkability properties of the PVLS transactions could be broken if they can be correlated with non-anonymous operations such as credit card payment or fixed IP addresses. Accidental or intentional system failure. PVLS server and client components could fail due to accidents (e.g., hardware failure, power loss, misconfiguration) or due to attacks (e.g., denial of service attack). In addition, system errors could result into incorrect transactions (e.g., receiving the wrong number of loyalty points, failing to receive discounts, etc.) Research challenges. Protocol design. Designing PVLS protocols will be challenging given all the system requirements and constraints. For instance, how to achieve and maintain the anonymity and unlinkability properties. In addition, how should loyalty points be managed? As an independent tokens or as a single accumulator/counter? Robust and efficient protocols. PVLS relies on complex cryptographic building blocks to achieve its security and privacy properties. Therefore, optimizing PVLS protocols to achieve adequate performance is important. The use of mobile platforms adds additional constraints. Secure and highly-available persistent storage. PVLS credentials, loyalty points and user profile information require a secure and highly-available storage. Cloud storage seems to be the best alternative. Still, providing adequate security in the cloud could be difficult. Efficient and reliable communication between the PVLS and the POS terminal. This communication channel should be easy to setup. Also, it should not hinder the customer shopping experience. WiFi and NFC seem to be the best options. Backup and recovery mechanisms. If any of the PVLS components fails, alternative mechanisms or procedures should be in place to guarantee the continuity of a transaction. In addition, it should be easier for the customer to switch smartphones in case of lost or theft Requirements Customer requirements Loyalty point transactions should be anonymous and unlinkable. Customers store and manage their user profile information and should be able to selectively disclose it to providers. The user profile contains not only transactional information but also additional contextual information gathered by the smartphone (e.g., location, time, etc.). In addition, customers should be able to see what information has been revealed and to what providers. The PVLS client application should be able to run in most mobile devices, including lowerend devices. In addition, it should support the main mobile operating systems (e.g., Android, ios, Windows phone). The PVLS client application should provide an easy to use, intuitive and responsive Graphical User Interface (GUI) to manage and use their loyalty points and user profiles. The PVLS client application should be able to verify the correctness of all the loyalty point transactions (e.g., loyalty points received, loyalty points used). Any errors should be reported in a easy to understand way to the customer. 10

15 The PVLS client application should allow customers to see the complete history of loyalty point transactions (e.g., earned points, used points, rewards, etc.). The PVLS should support different persistent storage options (e.g., SD card, secure element, cloud service, etc.). Moreover, it should hide the complexities associated with using a particular type of storage. The PVLS application should have a limited impact on the smartphone s battery life. Establishing the communication channel between the smartphone and the POS terminal should be easy for customers. Moreover, this channel should be reliable. Customers should be able to replace their smartphones without losing access to their data (e.g., credentials, loyalty points). Customers should be able to automate some tasks and configure their preferences through policies. Customer should be able to use the PVLS application with the loyalty programs of different providers. That is, it should support multiple types of credentials and loyalty points. Provider requirements The PVLS server application should have low infrastructure requirements. It should work with COTS servers and POS terminals. In addition, it should be compatible with existing services. The PVLS server application should be easy to configure, operate and maintain. In addition, operational and maintenance costs should be low. The PVLS server application should be able to verify the correctness of all transactions and detect and prevent fraud attempts (e.g., double-spending). Providers should be able to offer additional incentives to customers in exchange for additional data. The integrity of this data should be protected by PVLS. Providers should be able to include additional services and technologies to PVLS with low effort. Providers should be able to bind PVLS credentials and loyalty points to other customers credentials (e.g., BeID, driver s license) or customers smartphones to prevent unauthorized use of credentials and loyalty points. Functional Requirements Customers should be able to collect and use loyalty points. Customers should be able to decide when to use loyalty points. Customers should be able to build local user profiles and selectively disclose information from their profiles to providers. Customers should be able to review all their transactions, loyalty points status and information revealed to providers. Providers should be able to issue PVLS credentials directly or via a third-party. In addition, providers should be able to revoke credentials. Providers should be able to issue and validate loyalty points. In addition, providers should be able to determine the validity period of the points and to revoke them if required. 11

16 Providers should be able to implement and configure different types of loyalty programs and determine how loyalty points are used. Provider should be able to monitor how loyalty points are used by customers, but without affecting customers privacy preferences. PVLS should support both online and offline loyalty programs. Security Requirements Customers should not be able to forge or tamper with PVLS credentials and loyalty points. Double-spending of loyalty points should be detected and prevented. Providers should be able to disallow the sharing of credentials and loyalty points. The persistent storage of credentials, loyalty points and user profile information should be protected according to the customer s threat model. The provider s database with customer s registration information should be adequately protected. Backup and recovery mechanisms should be in place in case of any PVLS component failure. Privacy Requirements Customers transactions with providers should be anonymous by default. Customers transactions with providers should be unlinkable by default. Customer profile data is stored and managed by customers only. Customers should be able to selectively disclose information to providers as well as make some transactions linkable. In general, most of the information released should not directly identify a particular customer. Customers should have a complete view of the information released to providers. Providers should only store information revealed by customers during registration and transactions. PVLS should be resilient against attacks that try to break the customer privacy. PVLS deployments should take into account possible information leakages due to sidechannels such as credit card payments and network information (e.g., IP addresses). 12

17 Chapter 3 Family loyalty card 3.1 Introduction Existing loyalty programs usually offer family loyalty services to their customers. With this service, family members are issued with family loyalty cards. Using this loyalty card, family members can share earned loyalty points and pool the points each member collects. However, similarly to standard loyalty cards, current family loyalty cards are not privacyfriendly. Typically, family loyalty cards are issued as a group of cards linked together through their serial number(s). Providers keep a profile for each card or group of family cards. In addition, providers record all the purchases that are made and all the information that is provided during registration. Examples are retailing chains, such as Delhaize or Carrefour where customers provide their personal information in order to be issued with a number of linked loyalty cards. Moreover, some stores verify the address provided by sending the loyalty cards by post. The issuance of the family cards is usually performed by the provider without verification that only family members obtain them. The cards issued in one group are linked and the acquired loyalty points are pooled in one account (or several linked accounts). The provider issuing the points can see the link between cards belonging to a family scheme and can usually link them to an identity of the person that subscribed for the family loyalty scheme. PVLS can be used to implement family loyalty credentials. In this way, we can ensure that a privacy-friendly loyalty system such as PVLS can offer all the services provided by existing loyalty systems. This approach is important to guarantee that PVLS design is attractive to both customers and providers and it does not pose limitations compared to existing solutions. The goal of this service is to allow family members to pool their loyalty points together, without hindering their privacy. The PVLS family credentials can be thought as an extension of the basic PVLS scenario presented in Chapter 2. The individual members of the family membership do not need to be disclosed to the provider, while the provider can be assured that only eligible customers can benefit from the family loyalty scheme. Customers also need to be sure that belonging to a family scheme does not allow disclosure of information, which they are not aware of. Therefore, the PVLS credentials belonging to one group of customers should be issued under the same or under compatible privacy policies. 3.2 Use Case Stakeholders Customers (i.e., family members). 13

18 Provider. Issuer of the family loyalty credentials (it could be the provider itself) Assumptions. The provider defines the requirements that customers need to prove in order to take part in the family loyalty program. For instance, they could limit the number of family members that may participate or could require customers to prove family membership in order to be issued with PVLS family credentials. All the family members have a smartphone with the PVLS client application installed. Customers can download this application from any of the main application stores Scenarios In order obtain PVLS family loyalty credentials, customers follow a similar procedure as when standard loyalty credentials are issued. The main difference is that the family credentials need to be linked, i.e., have shared values, so that customers can prove family membership. To obtain the family credentials, a family member initiates the registration protocol with the issuer. For this purpose, the family member needs to prove her identity, to specify the number of loyalty credentials required and to agree with the privacy policy that all the family credentials should follow. In addition to the loyalty credential, the issuer also provides the family member with an appropriate number of tokens to be used by the other family members to obtain their respective credentials. These tokens (and other secret information to be included in the credential) are distributed to all the other family members. They use it when approaching the issuer to obtain their credentials, which are linked, so that merging of the earned points is allowed. This means that some information that the issuer can see should also be included in the issued credentials, so that the issuer can make sure that only the specified number of credentials for one family is issued. As in the standard credential scenario (Chapter 2), the credentials are stored and managed using the PVLS client application running on the customer smartphone. The overview of the protocol for obtaining and merging loyalty points in the family scheme is illustrated in Figure 3.1. The customers store their loyalty points in a secure cloud storage using the PVLS application. All the points gathered family group members are kept in the same storage. Cloud storage is important for the family scheme to avoid loyalty point synchronization issues if the points are stored locally on the smartphones of each family member. When a family member wishes to use the loyalty points, he would download all the points stored in the cloud storage to his smartphone using the PVLS application (Figure 3.2). The provider would verify that the points are valid in order to prevent double spending or points forging. Optionally, if the provider wishes to prevent (unauthorised) points sharing, it would also check that the customer is authorised to use them, i.e., that the points that are shown are linked to his loyalty credentials Threat model In addition to the general threats presented in Section 2.6.3, the family loyalty scheme considers the following threats: Non-family groups obtaining family loyalty credentials. The provider can specify the checks it requires from customers who wish to partake in the family scheme. This means that it can limit the number of credentials issued to a family group or may require actual proofs of family membership (e.g., shared address). Store obtaining the link between family loyalty credentials. If the customer policy specifies that the link between family credentials should not be apparent to the retailer, the 14

19 Figure 3.1: Gathering and merging loyalty points in a family loyalty scheme using PVLS. Figure 3.2: Using merged loyalty points in the family loyalty scheme. usage of other family credentials belonging to the same group should not allow for disclosures that break the policy rules Benefits Currently, the family loyalty cards are linked by the provider and are linked to all the purchases customers make. With the PVLS family loyalty credentials, purchases of different family members will not be linked and, even when the points are pooled, the information such as membership of a family group is hidden from the provider Research challenges In addition to the research challenges presented in Section 2.6.4, this scenario has the following specific challenges: The family credentials should be issued with a link that is hidden during their use, but that allows merging the points of group members. The PVLS client application should pool the points together in a user-friendly way, while preserving the privacy of the family members towards the service providers. 15

20 The design should allow linking new credentials to a family group or removing existing credentials from a family group. Family credentials should have the same or compatible disclosure policy, so that every customer is aware what information the provider can learn Requirements In addition to the requirements presented in Section 2.6.5, this scenario have the following specific requirements: General Requirements Customer requirements Customers wish to control the disclosure of their data, i.e., the disclosure policy for a group of family credentials cannot be changed without customer knowledge. Customers want assurance that their personal relationships (i.e., family membership) will not be obvious to the service provider, unless it is authorised to obtain this information. Provider requirements The providers can require a limitation on issuing the family credentials, e.g., limit on the number of family members or require a proof of family membership. Functional Requirements Customers should be able to obtain the family credentials in a user-friendly manner, e.g., simultaneous customers presence and engagement in the issuing protocol should not be required. Pooling of points should not require all group members to perform the protocol concurrently. Security Requirements Pooling points of non-group members of a family scheme should be prevented, unless it is explicitly authorised by the retailer. Privacy Requirements Family membership should only be disclosed with customer consent. Pooling of loyalty points should not disclose additional information, such as linking the purchases made by family members. 16

21 Chapter 4 Brand loyalty 4.1 Introduction Brand loyalty is a service that allows brands to measure and reward customer loyalty. Currently, there is no mechanism that follows specific purchases of individual customers in the long term and provides such information to the brands. PVLS can be extended to allow the brands to verify that a customer has purchased a certain amount of their products and drive customer loyalty by offering equivalent benefits. Currently, brands may issue discount coupons, which customers can use in certain retail stores. However, the coupons issued are based on a single purchase or purchases made in a limited time frame (e.g., limited-time promotions) without taking into account the loyalty of the customers. Therefore, such coupons do not reflect the customers long term relationship with the brand. One example are mail-in rebates where customers mail proofs of purchased products (e.g., receipts, barcodes) directly to the brand in order to receive a particular amount of money back. Still, the brand is able to collect customers personal information (e.g., name, address, payment method, etc.) while customers are not offered any additional rewards. Therefore, the goal of developing a brand loyalty service on top of PVLS is to offer a system that allows brands to directly measure and accordingly reward customer loyalty. In current systems, customers can establish a relationship with a retailer through the loyalty service, and are rewarded loyalty points for all their purchases, but there is no system for tracking and measuring their longterm loyalty towards a brand. 4.2 Use Case Stakeholders Customers. Brands offering rewards for customer loyalty. Retailers where customers buy products of a specific brand. Providers where customers could obtain the brand-loyalty benefits Assumptions Brands have implemented the PVLS server component successfully. If the brand-loyalty points are issued by retailers, then it is assumed that retailers made an agreement with the brand. 17

22 Figure 4.1: Brand loyalty points issued by different retailers. Customers could use their existing PVLS loyalty credentials to perform brand-loyalty operations. Brands can define what type of credentials from other providers could be used. Moreover, brands could issue their own loyalty credentials Scenarios Offering brand loyalty via retailers. When customers make a purchase, the retailer issues a number of brand loyalty points associated to a particular brand. The brand loyalty points are gathered in a similar way as the regular loyalty points of the retailer. The main difference is that the brand points incorporate an identifier that allows linking them to a specific brand (Figure 4.1). Therefore, when the customers wish to use these points, the brand or a provider can verify that they indeed correspond to the specified brand. When the points are issued, the store would also report the number of issued points to the brand. The brand would therefore be able to keep track of the points that are issued and the benefits that are retrieved by the customers. The brand loyalty points are managed and stored together with other type of loyalty points by the PVLS client application. Collecting brand loyalty points directly. The brand loyalty points can be collected by customers directly, without the involvement of a retailer (Figure 4.2). The points can be obtained via a code attached to the product itself. In this case, customers would need to scan or enter the code and contact the brand in order to register the points as belonging to them. Otherwise, if the product package is disposed of before the customer registers the points, the code could be used by another person who comes into possession of the packaging. In this scenario, the customers can obtain brand loyalty points independently of the retailer. This is important as not all retailers may have the PVLS in place. However, the customers are required to interact with the brand after every purchase, which may be a disadvantage for them Threat model In addition to the general threats presented in Section 2.6.3, the family loyalty scheme considers the following threats: Retailer issuing unauthorised points. If the brand loyalty points are gathered through a retailer, issuance of unauthorised points should be prevented. This means that the retailer 18

23 Figure 4.2: Brand loyalty points issued directly by the brand. should not be able to give disproportionate number of points to legitimate customers purchasing brand products, but also to pose as a customer and obtain all unused points. The latter is possible as the retailer can keep track of the brand products purchased without the customers taking the points that they were entitled to. The retailer can therefore pose as a legitimate customer and issue itself all such points in order to collect the benefits the brand offers. Since the number of issued loyalty points in that case matches the products sold, the brand has to have different means of protection from this threat. Customers collecting points from non-purchased products. If the brand loyalty points are issued directly by the brand through codes included in the products, malicious customers may try to scan such codes from the retailers shelves and claim the loyalty points without purchasing the products. Thus, the system should be designed to prevent such behaviour Benefits Currently, brands cannot measure customers long-term loyalty. With this approach, customers can be issued with loyalty points for every purchased product of a specific brand. The points can be issued by the retailer where the purchase is made or can be obtained directly from the brand, via a code given on the product itself Research challenges In addition to the research challenges presented in Section 2.6.4, this scenario has the following specific challenges: Specifying the brand loyalty points issuance and use. Countering possible misuse by retailers (cf. threats). Design a robust way for customers to proof they have purchase a product and to obtain the corresponding brand loyalty points directly from the brand. 19

24 4.3 Requirements General Requirements In addition to the requirements presented in Section 2.6.5, this scenario has the following specific requirements: Customer requirements Customers want a convenient way of gathering brand loyalty points directly and through retailers. Provider requirements Brands want to measure their long-term relationship with customers. Brands also want to get more data about customers purchasing habits without affecting privacy. Brands want assurance that customers are not issued with more brand loyalty points then they are entitled to. Functional Requirements In case brand loyalty points are obtained directly, without involvement of the retailer, customers should be offered a convenient way to proof they have bought a particular product. For instance, entering a lengthy code would be inconvenient for some customers, unlike scanning a barcode. Security Requirements The brands want to ensure there are no points abuses, e.g. customers being issued with a higher number of points than they deserve, customers double-spending points or forging them. The brands want to prevent that retailers pose as customers and collect all unused loyalty points. Privacy Requirements Customers do not want to be unconditionally identified when using brand loyalty points. Different purchases should not be linked when the brand loyalty points are used. 20

25 Chapter 5 Providers collaboration 5.1 Introduction In some loyalty program scenarios, providers have commercial contracts in which loyalty points from one provider are converted into points for another provider and, hence, they can be spent for reductions at the partnering provider. PVLS could be used in such scenarios with different loyalty programs from different providers. In this case, privacy is even more important, as transactional data from multiple providers is stored and managed by the PVLS client application. Currently, there are examples where such use cases are implemented. One such example is the collection of air-miles. Air-miles can be gathered when spending money at the airline provider, but also when booking a hotel room or rental car at a partnering provider. Likewise, air-miles can be converted into points for the hotel or car rental office, and get reductions in those providers. Privacy should be maintained when using PVLS for multiple providers, and when converting loyalty points from one provider, into points of another provider. The challenge here is to maintain privacy while supporting the commercial advantage of such contracts or at least offer a solution with a similar commercial advantage. In addition, it is important that PVLS guarantees the correctness of the loyalty point conversion operations and to prevent some providers to take advantage over others (i.e., fairness). 5.2 Use Case Stakeholders Customers. Partnering providers. Trusted third-party for loyalty point conversions Assumptions PVLS has been deployed in all partnering providers. Partnering providers have negotiated a compensation agreement where the loyalty points conversion rates are specified. The trusted third-party is also aware of such agreement. Customers have registered in the PVLS of all the partnering providers. That is, customers already have loyalty credentials for each provider. Trusted third-party is honest. 21

26 Figure 5.1: Collecting loyalty points in separated loyalty programs of partnering providers Scenarios Collecting and using points in separated loyalty programs of partnering providers. As with traditional loyalty programs of partnering providers, customers become members after they register to each of the loyalty programs separately. Figure 5.1 depicts how loyalty points are collected in the PVLS of a partnering airline provider, a hotel chain, and a rental car provider and how they are stored. Customers obtain provider specific loyalty points proportional to their purchases at the particular provider. These are stored in multiple secured cloud storages controlled by the customer s PVLS client application. Customers that collected sufficient loyalty points, have to download points to their smartphone before spending them. They present these during a next purchase at the same provider or at a partnering provider. This scenario requires a third-party that is trusted by all the stakeholders. The trusted third-party performs fair loyalty point conversions at the moment of spending between different loyalty programs. In addition, the trusted third-party keeps records of all the loyalty point conversions. Such records are then use by the trusted third-party and the providers to enforce the compensation agreement negotiated by the providers. Figure 5.2 illustrates how the points from the hotel chain and airline provider are used for a free car upgrade at the rental car provider. Obtaining and spending loyalty points in centralized loyalty programs of partnering providers. To improve efficiency, partnering providers fuse their loyalty point storage into a single secure cloud storage controlled by the customer s PVLS client application. A centralized registration procedure allows customers to become member of all loyalty program of partnering providers. Figure 5.3 illustrates how customers collect loyalty points and how they are stored in the centralized storage. Loyalty points earned at one provider, are converted by the trusted converter after collection into a fair equivalent of reference loyalty points. The latter are stored in the persistent loyalty point storage. To use loyalty points, customers download them to their smartphone and present them during their next purchases. Before using them, these loyalty points are converted to loyalty points of the particular provider. Figure 5.4 depicts how loyalty points of the airline provider and hotel are used to obtain a free car upgrade at the rental car provider. This loyalty system can be easily extended with new providers. It only requires updating the trusted converter s conversion list with the newly added provider. New providers that initially have no loyalty program can adopt the reference loyalty points directly instead of defining their own type 22

27 Figure 5.2: Spending loyalty points in separated loyalty programs of partnering providers. of loyalty points. Finally, the Loyalty Point Converter keeps records of all the loyalty point conversions to enforce the compensation agreement negotiated among the providers. Obtaining and spending loyalty points in advanced centralized loyalty programs of partnering providers. In the previous scenarios, fair loyalty point conversions are performed by the loyalty point converter. All loyalty points that are collected or used by the customer are visible to this single party. Hence, this party must be highly trusted by consumers. This scenario presents a more privacy-friendly multi-provider loyalty system. The actual loyalty point conversion is shifted to the provider where the customer wants to spend the loyalty points. For this purpose, each provider and the customers have a loyalty points conversion rate list signed by each provider. This list contains the loyalty point exchange rates agreed by all the providers. The targeted provider does the conversion based on the received list and keeps track of the other provider s loyalty points used during the transaction. This information is used later on to enforce the compensation agreement negotiated by the providers. Therefore, with this approach a trusted third-party is not required. In addition, the PVLS client application requires access to the conversion rate list to indicate the customer if he has enough loyalty points from other providers to complete the transaction. Furthermore, a centralized registration procedure allows customer to become members of all loyalty program of partnering providers. Figure 5.5 depicts the collection of loyalty points and how these are stored in the secured on-line storage that is controlled by the customer s PVLS client application. Figure 5.6 shows how these loyalty points are used at the rental car provider. The PVLS application, after checking the conversion rate list, sends the rental car company the loyalty points from the hotel chain and the airline company. The rental car company, using its PVLS servers, converts the hotel and airline points to its own points and proceeds with the transaction. Later on, the rental car company sends the hotel and airlines points to their respective providers to received the agreed compensation Threat model In addition to the general threat model presented in Section 2.6.3, this scenario has the following additional threats: 23

28 Figure 5.3: Collecting loyalty points in centralized loyalty programs of partnering providers. Partnering providers could offer more loyalty points than commercially agreed. Partnering providers that are malicious could collude to break the privacy protection offered by PVLS to obtain customer information. For instance, personal information acquired by one provider is shared with another provider. Partnering providers that are malicious could collude to break the anonymity and unlinkability properties of PVLS transactions. Malicious customers could influence the loyalty point conversion to obtain more loyalty points (e.g., manipulation of the loyalty point conversion rates) Benefits A more transparent and dynamic system in which providers may cooperate. For instance, adding new providers is easier because loyalty point conversion rates are managed centrally. A more transparent and dynamic system in which customers participate. customers can convert points via a single PVLS client application. For instance, Centralized registration (only in scenario 2 and 3) is beneficial for providers because customer registration information (e.g., name and address) is centrally managed. Updating this information is easier to manage. Centralized registration (only in scenario 2 and 3) is beneficial for customers because they only have to register once. When required, the customer has to update his registration information only at one place (e.g., when moving to another address). The usability of the PVLS is beneficial for the customer s loyalty towards partnering providers. There is a commercial benefit for partnering providers. For instance, it is more likely that customers book their flights and hotel rooms at partnering providers because they can collect extra loyalty points. 24

29 Figure 5.4: Spending loyalty points in centralized loyalty programs of partnering providers.. Figure 5.5: providers. Collecting loyalty points in advanced centralized loyalty programs of partnering Research challenges Preserving privacy, while supporting the commercial advantage of partnering providers. Guarantee fair conversions between PVLS of partnering providers. Preventing double spending is more challenging in multiple-provider scenarios. For example, a malicious costumer could try to spend the same loyalty points in different providers in a short period of time. To prevent this type of fraud, providers should be able to keep an online log with all the loyalty points transactions and query it every time a transaction occurs. However, such approach can be expensive and represent a single point of failure. More efficient alternatives may be required. 25

30 Figure 5.6: Spending loyalty points in advanced integrated loyalty programs of partnering providers Requirements In addition to the requirements presented in Section 2.6.5, this scenario has the following specific requirements: Functional Requirements Registration to the PVLS of partnering providers is user-friendly for customers. Updating personal information is easy for customers and partnering providers. The customer s profile information kept in the PVLS client application can be used during transactions with partnering providers. Converting loyalty points is transparent to the customer. Setting up partnerships between different providers is uncomplicated. Security Requirements The trust required in partnering providers is minimal. Conversions of loyalty points should be fair and correct. Privacy Requirements The privacy protection offered by PVLS can not be broken by partnering providers that collude. Anonymity and unlinkability of PVLS transactions can not be broken by partnering providers that collude. Customer profile data disclosed to one provider is not disclosed to partnering providers by default. 26

31 Chapter 6 Personal Shopping Assistant 6.1 Introduction PVLS can be extended to support a personalized shopping assistant, a service that adds value to both customers and retailers in the current practice of self-scanning or self-checkout. Customers, via the PVLS client application on their smartphones, can obtain on the spot recommendations and special discounts for additional products to buy. These offers are tailored to the customers personal profile, current context and any other real time factors (e.g., current trends among the store public) collected and managed by the PVLS client application. Thus, the personal shopping assistant gives retailers a new way of cross-selling or upselling while maintaining customers privacy preferences. Currently, the customers gain very little from the process of self-scanning. They may save some time at the checkout stand, but often the shopping cart contents is verified by a store employee. Vouchers and special offers are typically one size fits all and run for a fixed time in every store. Vouchers are printed on paper and distributed through newspapers or mass-mailings. Cross-selling methods for retailers are limited to putting products in close proximity to each other and various forms of in-store advertising (e.g., billboards, aisle displays, customized hardware displays). In addition, the retailer provides specialized hardware for self-scanning and checkout process. Our goal of is to extend the PVLS client application to create a smart shopping assistant that learns the customer s preferences to deliver personalized product recommendations and targeted coupon or discount offers. The shopping experience can be enhanced by a transparent, privacyfriendly shopping assistant that gives the customer insight into and control over what data is collected and disclosed to retailers. The retailers are able to directly target additional products, vouchers or special offers at the right shopper, even if that person has never before shopped in that particular store. In addition, using the customer s smartphone as a scanning device means the retailer does not have to provide the scanning equipment, and the checkout process can be integrated into a payment application on the smartphone. This approach means cost reduction, greater ease of use and time saved. 6.2 Use Case Stakeholders Customers. Retailer. Service provider through which the customer s smartphone retrieves vouchers or recipes (it could be the retailer itself). 27

32 Figure 6.1: Updating the shopping profile Assumptions To enable self-scanning, the retailer must place a 2D barcode, RFID tag or other means of identification on each product so that the customer may scan it with their smartphone. Personalization requires a product database that contains metadata that accurately describes each available product. In this database, each product has a unique identifier that is used in the barcode or RFID tag mentioned above. The database may also describe recipes consisting of multiple products. The product database can be provided by the retailer or a third party. The retailer provides WiFi via one or more wireless access points Scenarios Creating a personal shopper profile and recommending products. The customer scans a product with his smartphone before placing it into the shopping basket, triggering an update of the customer s personal profile in the PVLS client application. This process is shown in Fig The profile can then be used to recommend other products or offer a personalized set of vouchers, as illustrated in Fig The general steps for this scenario are: 0. The PVLS client application exchanges information with the PVLS server to receive customize offers and recommendations based on the initial costumer profile information revealed by the customer. Customers decide how much profile information should be revealed during this initialization step. 1. The customer scans a product with his smartphone. 2. The PVLS client application on the smartphone retrieves information about the product from the PVLS server. 3. The customer s personal profile is updated. This profile is stored in a secure cloud storage together with other customer s data (e.g., loyalty credentials and points). The cloud storage is controlled by the customer via the PVLS client application. 4. The smartphone retrieves product recommendations or vouchers for products that match the customer s preferences. The PVLS server provides these information based on the information in the customer s personal profile revealed to the retailer. This operation reveals only information allowed by the customer and, by default, it is anonymous and unlinkable. 5. The recommendations are shown to the customer via the smartphone s screen. 28

33 Figure 6.2: Recommending products or vouchers. Figure 6.3: Recommending similar products. Cross-selling through similar product recommendations. The customer scans a product and is told that customers that bought the same item, also had a preference towards certain other products. An additional discount could be offered on these related products. Fig. 6.3 illustrates this process. If the product database is aware of the products physical location in the store, preference is given to products that are nearby. The general steps for this scenario are: 1. The customer scans a product with his smartphone. 2. The smartphone retrieves products or vouchers for products that are related to the product that the customer has just scanned. 3. The recommendations are shown to the customer. Upselling through recipe recommendations. The customer scans a product and is informed that a particular recipe can be prepared with that item. This can also take into account other products already in the customer s shopping basket. The customer is informed what other products they need to buy and in what quantity, to be able to prepare that recipe. An additional discount could be offered on those other ingredients. The process is similar to the one illustrated in Fig. 6.3, but more advanced recommendation strategies are applied. The general steps for this scenario are: 1. The customer scans a product with his smartphone. 2. The smartphone retrieves recipes from the PVLS server that can be prepared with the product that the customer has just scanned. 3. The smartphone informs the customer what other ingredients they need to buy to prepare the recipe, optionally providing a voucher for those products. Real-time special offers. A substantial percentage of the customers that are currently in the store have a preference for a certain type of product. A limited-time special offer is 29