Affects Version/s: None
Fix Version/s: None
Component/s: User Management > Personal Data
Epic Status:To Do
GDPR's right to data portability ensures data subjects have the right to obtain and reuse their personal data for their own purposes across different services. The main goal is to prevent vendor "lock-in" where data controllers may take advantage of the significant effort required for a user to transfer their personal data to a competing or comparable service. Users can request a copy of all the personal data stored on a data controller in a machine-readable format, upon which the user can provide another service with the data and optionally invoke their "right to be forgotten" from the original data controller.
The personal data provided in the data export should only concern data provided by the data subject. Personal data includes data actively provided by the data subject (e.g. name, birthday, profile photos) but also data generated by the activity of the user (e.g. order history, customer service call records). By contrast, personal data that is derived or inferred is excluded (e.g. website browsing analytics) since such data is created by the data controller and not provided by the data subject.
As a data controller, I want a user interface to export the personal data of a user in a machine readable format.
Provide a UI and programmatic interfaces to export personal data stored on Liferay in a machine readable format when a user invokes his right to "data portability".
Liferay can provide a UI to create an export of a given user's personal data in a machine-readable format.
Every application within Liferay (whether a core app or third-party MP app) may store a user's personal data in various formats (table columns, custom fields, expando, files, etc). Some fields are clearly identifiable as personal data (a user's phone number, address, etc). However there is no reliable programmatic solution to determine whether the data stored in other fields (particularly for third-party apps) is considered personal data or not. For example, an image file associated to a user may have been uploaded by the user or it may have been a vanilla profile image automatically assigned by the third-party application. Given the indeterministic nature of how customers may be storing user's personal data, the expectation is that the application will need to determine where personal data may be stored.
To handle the data export, every application that stores personal data should provide an implementation that responds to a data export request for a given user. The data controller should be able to view which applications will export data (or simply, which applications have implemented this interface), and optionally deselect applications which may not be necessary as part of the export (e.g. test applications with dummy data).
Note, a user-facing (as opposed to admin-facing) interface to initiate the export is not necessary as data controllers will need to export and aggregate the user's data from every data system within the organization. The data stored on Liferay will likely be just one of many systems and will possibly (likely?) need to undergo some data transformation or processing before presented to the user. The data controller could possibly build a custom application that collects a user's personal data across all data systems, aggregates that data, then provides the finalized export to the user.
- Admins have the option to "export personal data" for a selected user
- Choosing "export personal data" presents a UI showing all the applications that store personal data. The list of applications is those that have implemented the programmatic interface mentioned below.
- Admins can optionally deselect applications to ignore for the export.
- Programmatic interface for applications to provide a user's personal data in a machine-readable format upon request