DIGIT CORE
Search…
Privacy Design
Proposed Design to support Privacy Principles
Personally Identifiable Information(PII) of every user should be stored in secured form in the data store. Plain access to any user data will be logged along with the purpose for the access.

Goals

  1. 1.
    To ensure data privacy, the data should be stored and communicated in encrypted form as much as possible.
  2. 2.
    By default, the secure data would be shown in a masked form. Only when the user explicitly requests plain data access will it be revealed in plain form.
    1. 1.
      Plain or masked access to the data will be role-based attribute-level access.
    2. 2.
      All the access to the secured data will be logged.

Architecture

There are the following two approaches to secure the data:
The details of these two approaches are explained in the next two pages. Either of the two architectures can be used to ensure privacy.

Plain/Masked Access

For all secured data, there will be two-level of access - masked and plain data. At first, based on the user's role, the requesting user will get masked values only. Only if the user explicitly requests for plain value will he/she get access to the plain value. The intention to get the plain values will be passed as part of the Request Header. All the plain accesses by a user will be logged. The Audit Log will contain the following details: requesting user's id, timestamp, data access policy used during decryption, the purpose for the decryption request, and the list of user ids whose data was decrypted. Based on these audit logs, any user can trace back who has accessed his/her data.

Taking the user's consent to use the private data for various purposes could be done at various granular levels. At a higher level, we can store the user's consent in the user service, and based on the user's choice, we can use the data across multiple modules.
Further details on Consent Management are discussed in Consent Based Architecture.

User Data Ownership

As we are storing all user data as part of a single user-data-management service, it should provide APIs so that a user can update his/her own data by providing appropriate proof.

Purpose Limitation

Before taking the user's consent, the purpose of the PII data usage should be defined in a precise and concise manner.
All content on this page by eGov Foundation is licensed under a Creative Commons Attribution 4.0 International License.
Copy link
On this page
Goals
Architecture
Plain/Masked Access
User Consent
User Data Ownership
Purpose Limitation