Introduction

In this guide, you will learn how to configure IBM Security Verify to comply with data privacy regulations and requirements. Data Privacy and Consent capabilities in Verify are comprehensive and are designed to close the gaps introduced between the compliance/privacy officer and the developer personas. Learn more about the concepts here. This guide is meant for Privacy Officers and Administrators.

We will use the example of a shopping cart application that needs to comply with privacy rules to illustrate the associated data privacy configuration needed.

Configuring attributes and purposes

It is expected that the user profile attributes have already been created. As part of this activity, privacy officers would review those attributes and link them to data purposes.

Gathering information

Attributes are generally user profile data items like an email. However, they are not restricted to this. Attributes can be used to represent any item that needs user consent. For example, consider that a user has to authorize a banking transaction. In this case, a consent is recorded indicating the transaction that has been approved by the user. In this consent, the attribute would be called Transaction ID and the attribute value would be the actual transaction identifier value.

Data purposes indicate the purpose-of-use for a requested attribute. This provides sufficient context to the user about how and for what purpose the data is used. For example, a online store application may need access to the user's email for the purpose of sending tracking notifications. The purpose-of-use in this case is Shipping goods.

Typically, the data purpose and the attribute associated with the data purpose is configured with access types. Access types indicate the access level. Verify offers a default access type called default that indicates that the user data access level is effectively indeterminate or complete. The access levels entirely depend on the data custodian. For example, data provided via profile APIs may be used by applications for the purpose of profile management. However, there is a need to provide an additional dimension that indicates the access level of data - read, store, etc. The consent record created would contain this information as well, which implies that an application requesting approval to use attributes for the same purpose but different access types will require different consents from the user.

You will need to know the following to complete setting up your IBM Security Verify tenant.

In a shopping cart application, some of the attributes of interest are user's first name, last name, full name, age, email, mobile number and home address. Purposes are tailored based on how the application intends to use the data. For example -

1. Shipping: In order to ship items that are bought by the user, the application needs the home address, the email and possibly the mobile number. The latter two would be used to send tracking notifications.
2. Profile Management: In order to display the user's profile information or "welcoming" them to the application, some basic profile information is needed. Some of the attributes of interest may be the first name, last name and full name. These would only be "read" and not updated in the identity provider or stored in the app database. So, the access type associated with this purpose would be "read".

---

NOTE

Access type is not standalone. It is always associated with the purpose or a specific attribute configured within the purpose.

---

Reviewing attributes

Attributes are generally user profile data items like an email. However, it can also imply an item that needs consent. For example, consider that a user has to authorize a banking transaction. In this case, the attribute may be called Transaction ID. The consent statement created on user authorization would include the actual transaction identifier as the attribute value.

In Verify, attributes are configured in the Admin Console (https://yourtenant.verify.ibm.com/ui/admin) under "Directory > Attributes" in the navigation panel. Verify supports different types of attributes:

1. User schema: There are two categories - built-in/predefined attributes and custom attributes. These attributes can have actual associated data per user account that is stored in Cloud Directory.

2. Identity provider credential: These attributes are part of an external identity source token that becomes available to Verify when the user authenticates into the system. These are ephemeral and not stored in Verify.

3. Advanced rule: Values are computed using scripts. They are not persisted in the Cloud Directory but can be computed and included in data shared with applications.

4. Fixed value: These are typically used to define a static value or as a placeholder. For example, the Transaction ID attribute would be a fixed value with no global value defined. It is merely a placeholder that is used purely to link the transaction ID value provided in the authorization request with the consent statement.

Data privacy officers and administrators would typically review the attributes available to configure Data purposes. This can be done by going to "Directory > Attributes" or by searching for the attribute when creating the purpose.

Configuring data purposes

Purposes are central to Verify Data Privacy and Consent. It indicates a purpose for which an application may use the attribute. Access types are configured with purposes.

In order to illustrate the steps better, we use the Shipping purpose here.

1. In the Verify Admin Console, go to "Data privacy & consent > Data purposes".

2. Click on "Create purpose".

3. Follow the steps to create a purpose with ID shipping, use the system-defined default access type and associate attributes Home address, mobile_number and email. When saved and published, it should look like this.

   

Repeat the steps to create additional purposes.

Configuring the privacy policy

The privacy policy is a collection of rules that is executed on every data usage approval request. The rules correspond to regulations defined by government, some governing body and/or the organization itself.

We use a special rule for the Shipping purpose here that requires a opt in/out type consent.

1. In the Verify Admin Console, go to "Data privacy & consent > Data privacy policy".

2. Switch to the "Rules" tab.

3. Click on "Create rule".

4. Call the rule "Shipping rule" for simplicity.

5. Add a condition with "Condition type" set as Purpose and value as Shipping.

6. Select consent type as Opt-in or opt-out of purpose.

7. Leave "Opt-in/consent is selected by default" unchecked.

8. Leave decision as Explicit consent.

9. Set activation and expiration dates if needed. This determines when the rule is active.

10. Once created, the rule should look like this:

    

Once all privacy rules have been added, they need to be added to the policy and ordered correctly.

1. Switch to the "Policy" tab.

2. Click on "Edit policy".

3. Add rules to the policy and order them. Notice in the image below that a rule is pending activation and will become the highest priority rule on the date indicated. Similarly, notice that the Singapore specific rule precedes the Shipping rule.

   

Next steps

1. Application owner or admin adds purposes that are allowed for the application.

2. Developer integrates using Open ID Connect web based flows or OAuth authorized APIs.