Dealing with data privacy

Brand equity and reputation hinges on proper consent and data privacy stewardship. Compliance regulations are changing fast and growing in both complexity and scope, especially when it relates to user data privacy and personally identifiable information. In addition, users are expecting greater transparency and autonomy over their data. In particular, regulations require users to be informed as to what is being collected, why is it being collected and give them control over how long they choose to share this data. Developers continue to struggle to keep up with the latest regulations and to parse legal jargon into code and pleasing experiences. The siloed interactions between the developer and privacy officers make implementation a challenge. As new laws become reality or old laws change, this can have major business impact.

IBM Security Verify offers a holistic and advanced privacy and consent management system that allows the following:

Streamlines workflows across stakeholders - the compliance officer, the developer, the line-of-business owner and the consumer.
Data privacy officers are able to author privacy rules as regulations evolve, without requiring the developer to modify applications. Furthermore, these rules can be activated based on regulatory timelines.
Developers comply with privacy regulations either through enhanced OAuth or Open ID Connect flows, or through direct integration with well-defined application programming interfaces (API) that guide the developer through the assessment and consent collection process. All of this can be accomplished with little to no understanding of privacy laws.

Purpose driven privacy and consent

In IBM Security Verify, Data privacy officers, through dedicated screens in the UI portal, can define data privacy and consent rules that apply to their industry and geography. These rules can be modified at any time and take immediate effect on applications that perform the data usage approval assessment to request data. In addition, data privacy officers can manage data purposes and associated attributes and indicate a need to ask the user to re-consent because of significant changes. All of these self-service capabilities use recognized privacy terminology and without writing code.

Core concepts

Consider a shopping cart app that needs the user's home address to ship items to them. When the user begins the checkout process, the app would need to check if it is authorized to use the user's home address. The following diagram illustrates the standard flow.

This assessment can involve different decisions:

Allow if the user has previously consented to share this information.
Deny if the user has declined in the past and requested to not be notified again. It might also be the result of a privacy policy rule that disallows access to this data, possibly outside of a specific geographic location.
Requires consent if the user has never previously consented to sharing this data. It might also be the result of a previous consent expiring either as a result of a validity period or a change in regulation that requires the user to re-consent.

With this example, there are three key concepts being introduced.

Purpose of use indicates why the app requires access to the data. "Shipping goods" is quite distinct from "sending promotional material".
Attribute indicates the actual data being requested. In the example, this is the home address.
Privacy rules authored in the consent management system evaluate to offer a decision.

About consent statements

Broadly, there are two types of resources that can be created in IBM Security Verify that form the basis of consent:

End user license agreement: Based on the application, it may be mandatory or optional for users to agree to a terms of use/privacy notice document before gaining access to an application's services.

Purpose-of-use or Purpose: A purpose-of-use indicates the reason for which the application is requesting the use of attributes or perform actions. For example, when a user visits a typical shopping cart app, the app requires the user's home address to ship goods. The attribute in this example is the user's home address and the app needs this information for the purpose of shipping goods.

In IBM Security Verify, the purpose-of-use consent statement can be quite granular and can include the following:

Purpose-of-use is the purpose for which the consent is being requested. For example, sending a tracking number for the purchase.
Attribute is the user attribute that the user is being asked to share or represents an action that the user is allowing the application to perform. For example, the user's email.
Attribute value is an optional value of the attribute. For example, a specific email address.
Access type indicates what the application is entitled to do with the data and whether they can update the value in the source repository, for example.
Validity period indicating when the consent is activated and when it expires.
Consent type that indicates the style of consent. This includes 3 possible types:
o Allow or deny is the typical consent type and simply indicates whether the user approved or denied the use of data
o Opt in or out is a more precise form of consent where a user may choose to opt-in to a service, optionally by providing access to data, or explicitly opts out. This terminology is common in privacy laws like the European Union GDPR regulations.
o Transparent is a form of consent where the app informs the user that proceeding to use the services offered implies an approval.
Custom attributes add any level of fine-grained context to the consent record.

Condition driven decision engine

Acting as a central authority for data usage, Verify allows privacy and risk officers to enforce privacy laws if the application uses Open ID Connect federated flows. Alternatively, Verify acts as a privacy decision point for applications that are expected to comply with the data usage approval decision. Rules, governed by global conditions around purpose, attributes, geography, will provide an authoritative decision on how data can be used and how consent must be captured if the condition is met.

Provide transparency to end users

Given granular data privacy and consent rules can be applied, marketing and business owners can ask for the right amount of information while practicing proper data stewardship. You don't have to over collect and you don't also need to under collect user information. You can collect exactly what is needed while giving consumers the transparency into why the information is being collected and what the information will be used for.

Low code / no-code privacy and consent enforcement

Developers can remove the guess work of having to know and apply the proper data privacy and consent rules. Instead, developers can focus on core application development and comply with data usage approval decisions rendered as an API response based on rules defined by Data Privacy Officers. As rules and End User License Agreement Versions are updated by the Data Privacy Officers, they automatically get reflected in the application without the developer having to intervene. Developers may also leverage standard Open ID Connect authorization flows to delegate enforcement and consent collection to the Verify Open ID Connect Provider.

As part of this, developers can make use of two integration patterns -

Using Open ID Connect scopes or other custom request parameters that translate into consent requests: With this, developers continue to use existing OAuth SDKs/implementations to provide more expressive scope values in the authorization request. These are translated into more granular consent authorization requests and statements which are shown by IBM Security Verify when users access the application.
Using direct REST APIs or the Privacy SDK