In this series we look at practical tips on how to configure the Ubisecure Identity Platform for GDPR compliance. This second entry deals with GDPR compliance in terms of data collection and disclosure and how your organization can move towards compliance by configuration of the system. We’ll look at Persistent ID, Transient ID, Authorization Policies for Attribute Release and Incremental Registration.

Avoid sending sensitive identifying attributes by instead using Persistent ID

Especially for applications that are outside of your organization, consider the use of a Persistent ID as way to link a user’s login account with a third-party service without exposing explicit personal user attributes.

How does it work?

During every login, the identity server checks to see if the user has accessed the application before. If not, it generates a random ID and sends that to the application instead of any actual user attributes. The connected application gets the Persistent ID and uses its own techniques to collect data about the user (for example asking them for some basic attributes). It is a non-public, pair-wise pseudonym intended to prevent the tracking of a user activities by making the linking of user across services more difficult.

When the user accesses the application again, we find the previously sent ID and send that again. The connected application stores the Persisent ID and uses it to lookup the user account. If the same user accesses a different application, it will get a unique persistent PersistentID. This can help to design systems to reduce information sharing and user tracking between connect applications.

How to configure:

For every application that should get a unique Persistent ID, create a Mapping Table of type Persistent ID and attach it to the Agent. When the user is logged in, the NameID or sub value will be replaced with Persistent ID.

In the example below, an application for showing a daily lunch menu at the office building really doesn’t need to know my name or email address. However, by giving the application a Persistent ID, it can still remember my food preferences for the next time I come and always show my preferred foods first and hide the choices containing foods for which I have allergies.

The same Persistent ID Mapping Table can be attached to more than one agent. For example, if a logical service is made up of a series of different applications, which need to share a common identifier for the user, they can all be given the same Persistent ID when a user accesses each service. The SAML standard uses the term “affiliation of service providers”. A field is provided to set the Affiliation ID that will be sent in those cases in the SPNameQualifier value.

In the OpenID Connect profile used by GSMA Mobile Connect, Persistent ID has been called Pseudonymous Customer Reference, or PCR for short. It has a defined format (UUID) that must be used and will be sent as the subject (“sub”) value.

User anonymization using Transient ID

To give user increased anonymity and to reduce tracking ability even between accesses of the same application by the same user, a Transient ID can be used. This is an identifier that is generated on the fly on each application access and is destroyed upon logout.

In the example below, an application for completing a feedback survey that has a Transient ID mapping table connected to it, will get a unique NameID every day I complete the survey.

Authorization policy considerations

Only give applications user attributes on a “needs to know basis”. Follow minimal disclosure principles.

Remember to review any Authorization Policy used to remove any explicit personally identifiable information (PII) – there is little point generating a privacy protecting Persistent ID if PII is sent anyway as an attribute. Depending on the use case and jurisdiction, the Persistent ID may also form personally identifiable information itself.

Attribute release can also be controlled based on the permission granted and collected from the user for the use case. In this case, the attribute should not be mandatory and the group that determines whether the attribute is sent should be defined based on the attribute or group membership representing consent.

Incremental registration

Don’t ask for all sorts of information about your users at the the time when they first register. Collect data as required along with the permission for the purpose of use. This is the right time to tell the user why you are requesting their information and what the benefit of giving it is. For example, don’t ask for a delivery address until the user needs to send a physical package. A user is more likely to give data at the time there is a clear logical connection for the purpose of the data collection.

User attributes and related metadata about those attributes can be collected by an application as required and updated to the user record at anytime using the CustomerID REST API. Sensitive data fields can be encrypted. Use the MOD004 Update User REST call.

Summary

NameID mapping using Persistent and Transient IDs, tightly managed Authorization Policies for attribute release and Incremental Registration are some the ways to make sure user information is collected at the right time, with the right permissions and that sensitive attribute data is shared only when required and only to trusted and authorized target applications.