domain/subject area: location information, tv viewing behavior, interest profiles.
event/situation it applies to: user with a mobile phone before or during a day out.
actors/entities involved: a telecom provider (the data controller), its customers (the data subjects) and optional cloud providers (data processors).

Use-Case Overview

Proximus is a Belgian telecommunications provider offering telephony (landline and mobile), internet and Internet TV. Their use case foresees the creation of a tourist recommendation tool on the basis of customer interest profiles. The tool is aimed to promote visiting of the Belgian coast and to test the willingness of people to share personal data to receive recommendations.

1. Categories of personal data involved

Mobile telephony data (GPS location of mobile device, or of the antenna having the connection)
Data created by the usage of other services provided by this controller (e.g. TV viewing behavior)
Public event database, e.g. dates of concerts, sports events...

2. Purposes for personal data handling

Providing personalized event recommendations based on location + interests, derived from the information from the data subject's profile.

3. Different kinds of processing of personal data involved

Aggregation
Categorizing into interest keywords
Matching interest keywords with event keywords

4. Data subjects, Controllers, Processors, and Recipients involved

Data subjects: Users of the event recommendation app who are also customers of Proximus telecommunication services and/or other services (like TV/internet)
Controller: Proximus as telecommunication service provider and provider of the event recommendations app
Processor: None (no further parties involved in this use case)
Recipients: None (no further parties involved in this use case)

5. storage & security aspects

Storage Duration

Multiple storage durations are thinkable in this use case, depending on what options the data subjects are given to tweak the storage period directly in the event recommendation app, or at least via the dashboard.

It could perhaps be desirable for the data subject to keep track e.g. of the locations and other data which served as basis for event recommendations. Or else, if the data subject has no interest in this and wants to retain as much data minimization as possible, he/she could be given the possibility to choose "no retention", too. The provider may set a data protection friendly default option.

Moreover, the storage period must be determined for each individual data category involved.

Examples for storage periods thinkable in the context of this use case:

delete-by_ or delete-x-date_month_after <event>

  For example, three month backwards from now on you can still review your own data in a dashboard.

no-retention (no storage beyond using once)

  For example, location is used as information to give an event recommndation for this area, then the location information is   
  disregarded/deleted.

stated purpose (until purpose has been fulfilled)

  For example, as long as the data subject is using the event recommendation app.

6. Means of Legitimation for Personal Data Processing

Consent on the basis of Art. 6 para. 1 (a), 4 (11) and Art. 7 GDPR

7. Policy language

A usage policy language is meant to express both data subjects’ consent and data usage policies of data controllers in formal terms, understandable by a computer, to automatically verify that the usage of personal data complies with data subjects’ consent. For an industry partner the challenge is to convert the theoretical basis of the policy language into a workable product. This has been accomplished with the help of Consortium partners CeRict and TUB. The following figure explains the relation that exists for a data subject between permission (=consent), policy and data.

Below is a theoretical example of a possible implementation of a policy for the Proximus use case:

P2: Use personal data for recommendations

{ hasData: { Personal Identifiable Information AudiovisualActivity + Demographic + Location + Navigation + OnlineActivity + TelecomActivity }

hasProcessing: Collect + Copy + Transfer

hasPurpose: PxsEventRecommendation

hasRecipient: Ours

hasStorage: { hasDuration: StatedPurpose durationInDays < 42 hasLocation: { EU ControllerServers } }

hasLegalBasis: Art6_1_a_Consent

hasDuty: GetValidConsent

}

The above example is formulated in an extension of JSON, that can be related to the standard OWL2 formulation: • curly brackets correspond to ObjectIntersectionOf • ‘+’ corresponds to ObjectUnionOf • has XXX:Y corresponds to ObjectSomeValueFrom(hasXXX,Y)