Identity: A Foundation for Privacy

A robust digital identity architecture is fundamental to good security. As digital identity professionals, we frequently work closely with security teams. It’s not uncommon for the identity team to report up to the CISO. The relationship between identity and privacy is less well defined – and it’s time that changed.

In the security world, the last few years have seen a rapid and complex shift from the traditional ‘fortress’ architecture to a more nuanced, and more complicated, landscape of deperimeterization, zero-trust networks, in support of a huge shift in the range of ways people (and devices, and things) access network services. The privacy landscape is going through a similar shift.

Even if your business is not directly affected by the General Data Protection Regulation (GDPR), or by the evolving privacy landscape in North America (witness the advent of the California Consumer Privacy Act (CCPA) and the recent publication of the Privacy Framework Outline¹ by the National Institute of Standards and Technology (NIST)), or by evolving regulations in China, it’s a safe bet that privacy will increasingly become an important consideration for business leaders – in many cases, a strategic imperative. This isn’t just about check-box compliance: as with identity, the c-suite is coming to understand that a solid privacy design not only reduces business risk but can also provide significant competitive advantage.

There are several key areas that digital identity professionals should focus on to help transition to a privacy-aware identity organisation. The good news is that many of these are consistent with and supportive of existing security and/or usability missions. And what’s more, these are all things you should be considering as generic good practices.

***

It’s all about data, baby!

A key outcome of most privacy (re-)design is that the amount of personal information that is collected, processed, and stored should be minimized. Asking the user only for that information which is relevant and proportionate to the reason you are collecting it is an obvious benefit to the user in terms of usability. Reducing the amount of information you are handling and storing has equivalent benefits in terms of reducing risk (particularly the potential for exposure in the event of a data breach, and, indeed, the likelihood of a deliberate breach attempt, since there is less data to go after), and reducing the cost of storing, processing, and maintaining the dataset over time.

Bear in mind that in some regulations — GDPR is one — there is a burden on you to allow individuals easily to view, update, and request deletion of personal information that you hold on them. Clearly, the less you have, the easier this will be.

Reducing the amount of information you request, process and keep is perhaps the most important adjustment you can make – although it may also be the hardest. Project stakeholders often want to collect more information than is strictly needed, and they often have very open-ended “reasons” for wanting it (which leads to overly long data retention).

Consider too whether users actually need to ‘create an account’ or whether there’s an alternative. For example: if users are federating in, you could simply use claims from the incoming assertion or ID token at runtime rather than having to persist that information in a traditional user directory or table.

Once you’re sure you’re down to a minimum, then consider who will have access to that information… and remember that this will include people on the identity team as well. Privileged access management can help here, as will safe storage of the data with appropriate encryption mechanisms.

Consider your Cloud(s)

In several of the extant regulatory regimes — again, GDPR is a standout example, but similar requirements obtain in applicable parts of Chinese regulations and associated technical guidance and to some extent in the CCPA — you will be required to track what data you send to third parties to process, and how that data will be handled.

Recognise that this may have implications for your identity architecture. Do you use a cloud directory, or a cloud-based SSO service? Do you provision users to your SaaS vendors? Do you host part of your identity infrastructure on AWS? All these might require documentation and, potentially, privacy agreements to be established.

This shouldn’t be seen as an impediment to cloud deployments! Rather, in being aware of the requirements you can better support your privacy team in their responsibilities.

Standard-bearing

Ensuring your deployments are using well-established standards, where possible, will also help you ensure a good privacy posture, and will give you fewer exceptions to check. If, for example, you have suppliers federating in to your systems, enforcing SAML and/or OpenID Connect rather than a proprietary protocol helps reduce the risk that data might be exposed in transit; and potentially reduces the need to manage and maintain additional personal information about those external users.

Keep a watchful eye on new protocols too – standards like User Managed Access (UMA)² can be useful in some cases; and there is ongoing work in the distributed identity arena which may prove helpful over time. Equally (as the French Data Protection Authority CNIL has observed³ in the context of Blockchain), new techniques may introduce novel privacy considerations: bear these in mind as well.

***

This is not intended to be a comprehensive collection of considerations, but it should be enough to get you thinking about the areas you can help your privacy team… if you have one! Lots of companies don’t, and you may suddenly find that you have taken ownership of a privacy program yourself. If you need to learn more, there is lots of good material around that will help. If nothing else you should check out the International Association of Privacy Professionals⁴ (IAPP) as a reasonable place to start.

Without good identity architecture, privacy efforts are doomed to fail. In supporting privacy initiatives, though, good identity architecture also supports other security and business objectives. In some cases, the identity team can usefully take a lead on privacy projects. Start by considering your existing architecture and explore which areas you can quickly improve, and look for tie-ins that will support other initiatives within your organisation.

Andrew Hindle
IDPro Board Member, Chair of the Editorial Committee