Being a Smart Customer — Open ID Architectures
Newer generations of ID technologies make the world of identity systems more interesting and visible — and invite a second look at the wider systems design principles and smart customer behaviors.
Today, everyone can see the world of identity changing from the outside. We use ID management tools such as mobile phones every day of our lives. We prove our identity and authenticate ourselves online so often that we seldom give it a second thought. We speed through fast border control without stopping to remember the past (and sometimes even our bags).
Smarter Devices — Smarter Customers
Increasingly we use and choose smarter devices, and we are becoming smarter customers. Many of these changes have been driven by the retail side of the identity business.
A consequence of this change is that individuals — or “end users” as the ID management world likes to call them — have become a new voice in the market for personal or private management of identity.
What Lies Beneath with Identity Systems?
Most consumers know that the tip of an iceberg is just the visible and smaller part of the story. Most of an iceberg lies beneath. If we follow the iceberg analogy, then we might infer that most of those making good use of these new identity tools are increasingly aware of an identity management world where ninety percent of the solution is under the surface. There are already signs of consumer-level concerns on this topic: users assume that so much beneath the waterline must mean that there is a lot going on with their private data.
The identity solutions industry has not been slow to respond, but arguably it has not been leading the charge around all of these topics. This is excusable in some cases because suppliers do not always own the design of wider end-to-end programs or systems and are simply contributors.
In response to the personal adoption of identity self-management, and to the revenue that follows it, the smarter (in this case more agile) identity technology companies have increased their effort to understand which experiences the smart end user would like to have. If an end user makes a consumer choice based on color and screen design, then this will be a design factor; perhaps even the deciding factor for some parts of a wider solution. If the end user is the integrator for the software application (i.e. she installs the application herself to her own device) then installation procedure will rise to the top of the buyer selection criteria list.
Privacy by Design
The bigger questions concerning the unseen 90% of the iceberg have been slower to filter down into the marketplace. The most accessible of these is the governance question of privacy of personal data. Much use is made of the concept of “Privacy by Design.”1 In simple terms, anyone accountable for an identity solution with a similar regulation in force should be able to explain and manage the PII data in their legal or operational care.
Another rule of icebergs is that where you find one, there are probably others nearby. The same is true of identity systems. Where you find identity data in one system, then you will probably find a nearby system that wants to make use of that data. From a privacy perspective connectivity carries responsibilities, and governance of what data gets passed between (sub)systems should be considered at the level of the systems’ purpose. One way to control this better is to share and use common, open ideas of identity management architectures; to have a shared understanding around their component systems and their connective principles, in this case Application Programming Interfaces (APIs)2 . Open API initiatives taking place today in the identity industry make it easier for customers to keep a constant watch on the risks posed to important topics like privacy.
When ID was Smaller
When identity systems were smaller and dedicated to simpler tasks, the government customer’s job was easier. In the early days, before the ice pack separated into individual bergs, one supplier might provide the full system and support all accountability for the system. This scope has grown and may still be the ongoing role of systems integrators, but in the modern world systems are built from multiple components and government customers no longer wish to be locked into the concept of having all those components from a single technology supplier. What customers ask for is a predictable level of interoperability between key components in a wider systems architecture.
The concept of interoperability works on many levels. ICAO, for example, has driven a concept of business-level interoperability for travel documents where the documents, readers, and the data shared by one vendor’s technology will work with another vendor’s. This combines interoperability between countries as well as technology types. Interoperability is not traditionally part of the design within integrated systems architectures. Components may have their own APIs, but these are typically 100% proprietary, even where the connecting methods are not.
HID participates in leading the efforts to create internal systems’ API standardization. With this standardization, core identity systems functionality can be supported across a range of diverse supplier components, ensuring government customers’ systems are competitively designed and will be manageable over time. The voices driving this are the customer’s and APIs. The products themselves will continue to grow over time, becoming richer and more widely adopted where they deliver most customer value. This is a market process as well as a technology.
The future of identity architectures is already evolving both above and below the waterline, becoming a more consumer/customer-centric proposition; and this looks set to continue with HID and many leading industry vendors on board for the voyage.
Learn more about what puts identities at risk in this executive brief.
Calum Bunney is Systems Product Director for HID Global Citizen ID. He has worked in citizen identity management for 25 years.
1This idea was almost forged in the crucible of European data protection law, and stated literally in the General Data Protection Regulation (GDPR) in force from 2018 in the EU.
2API – Applications Programming Interface. Roughly speaking, a technical definition of how a system or service will allow another such system to connect for the purpose of using or sharing its services and data. A system may implement or use one or more APIs.