Back in the day, a new idea was floated called “layered security.” It was a model that helped an organization plan out how to secure across all the touchpoints of the business; each layer protecting against a threat. Layered security evolved into the more holistic “Defense in Depth.” This new model was based on the philosophy of the whole being greater than the sum of the parts. It is a good model to follow and one that I believe the digital identity space can replicate. Here's how.
What is identity data layering?
The word ‘identity’ conjures up an emotional response. And why not? It refers to our very being. But the actual use of a digital identity is not really about me, myself, and I. It’s about me doing stuff online (or offline as the use case may be); digital identity in the consumer space is about people and data. Identity is almost a lost cause, as I mentioned in a previous article “Is it time to drop our identity to become frictionless?” Identity, in and of itself, is not the issue — it is how we present data to do a job that matters. Now, this data, which may represent some or many aspects of personally identifying information (PII), are best utilized on a need to know basis. If you work outwards from that premise, you also start the process to design using privacy as a remit.
People and data doing jobs need conduits or facilitators to work with and across. This is where the idea of ‘identity layering’ comes in. And, it is an architectural concept that is the key to making consumer IAM more than just a marketing tool.
Identity data layering allows the PII to flow but under the control of the user within the constraints of rules.
What are the layers of the identity ecosystem?
I’ll explain the concept ‘layered identity data’ using an analogy. An electrical network provides a means of matching up very different sources of electricity and consumers using a layered network that provides switching and transformation. This sort of network can funnel through, and transform as needed, the right type of electricity (high voltage, low voltage, AC, DC). Data in a CIAM system often needs to follow complex pathways and move through varying services doing different jobs at each – which need to be matched, just like in our electrical network analogy. In a similar way, personal data can flow across an ecosystem that is built up from multiple layers of components that offer different conditions, varying use cases, and shake hands with a variety of services. But, unlike electricity, human beings, especially internet savvy consumers, need to have high levels of flexibility in how they transact data and they also need a really great UX. This translates to “Consumer IAM” (CIAM) having the ability to seamlessly move data between services under the user’s remit.
The currently accepted way of designing an identity ecosystem for sharing data is via a platform architecture. This is often hard-coded to provide identities that respond to the calls of a relying party, “Send me your age and I may grant you a bottle of whiskey and do it under my version of SAML 2.” This has limited capability because it is too constrained. Making changes to such a system is hard. Adding in extra relying parties can be onerous, requiring federation and business models that are complicated. Even changing/adding things like a new communication protocol can get messy. It needs a shake up and this is layering.
Layering identity data is really about placing the data as central to the argument. The “layers” in this context give the system the means of change. Instead of a platform of hard-wired connected services you have a free-flowing conduit structure that can move through the components of the system in a fluid manner.
4 rules of engagement
Layering is about being able to pull in pieces of the identity data service ecosystem as you need them. It is about having the flexibility to be creative with technology and not constrained by a platform. There are certain basic rules that need to be applied when beginning to design your layered identity data system.
Agnosticism: Ok, so sometimes a MUST in a requirements list is a must. However, using tools that are agnostic to, for example, a database type, or that have multiple options for protocols choices, will allow you to move with the times. Having as much agnosticism as possible in the system will future-proof your ecosystem and give you choices. Technology changes quickly and the last thing you want to do is to re-engineer your system from scratch to accommodate a more flexible protocol or more robust authentication method.
API-led: Using an API that offers a good level of agnosticism is a key requisite of building your flexible ecosystem. An API that plugs the gaps will give you the tools to build the layers of the identity data conduit. An API-approach to building these systems allows for the flexibility needed to design future-proofed data services.
User-centric: Besides this ethos being a key part of data privacy laws such as GDPR, having a user-centric remit in your design, offers a way to connect the layers. Users know what they want to do with their data; they just need a layered method to do it easily.
Rules and constraints: Designing a seamless and free-flowing identity data ecosystem is fine but without rules and constraints applied in the right areas, it will fall at the first hurdle. Adding controls across the layers will ensure that you can apply security and privacy controls.
It's about teamwork
Having a layered approach to designing an identity ecosystem does not mean you cannot have key components like a “data store”. However, it allows you the freedom to think of these components in a more creative way. Your “data store” becomes a “data conduit” freeing it up from the idea it has to act like a store but could instead be like a middle-person who facilitates the data traffic between entities.
The whole system acts as a true ecosystem wherethe whole is greater than the sum of the parts — each loosely coupled until they meet up under the user’s control and the system rules. To build “personal data facilitation engines” we need to allow the system to work as a finely tuned team, each member component being part of a deeply integrated but fluid piece of a much larger puzzle.