Proponents of digital identity say it can make everyday life simpler, reduce fraud and improve security. Stated benefits include speeding up bank account applications and proving your right to work instantly. It can also end “identity exclusion” for people who have the right to live and work in a country but lack the documents to prove it.

But the public response has shown that the general population is wary. Critics say that they fear state overreach, data misuse and surveillance. Recent IBM research shows that only 1 in 3 citizens have high trust in central governments, a sharp drop from pre-pandemic levels.

The world’s largest ID system, India’s Aadhaar, has over 1.3 billion users and has been in place since 2009, but it still faces protests. When the UK recently announced plans to introduce compulsory digital ID, a petition to Parliament titled “Do not introduce digital ID cards” quickly gained 2.8 million signatures.

The “privacy paradox” we first identified in 2008 comes into play here: technology has the power to both empower citizens as well as control them. Seventeen years later, the question remains: how can governments build an effective digital identity infrastructure while also earning public trust?

The key lies in creating a system that people believe in, not just comply with; one that is built for broad acceptance, human-centred and secure. Read on to learn how.

Be accepted: Build on familiarity and integrate open standards

To create a system that people are willing to trust, adopt technologies and processes that are already in use. Smartphone wallets and face authentication feel natural to the millions that use them daily. Familiarity builds confidence and drives adoption.

Build on existing initiatives, for example national single sign-on for digital government services, such as the UK’s GOV.UK One Login. Integrate existing processes, data and systems, rather than creating new silos; use open standards, such as verifiable credentials. Integrated standards-based solutions accelerate adoption, provide flexibility and improve value for money.

Learn from success stories. Estonia’s digital identity system covers 99% of citizens, supports digital and traditional processes and enables everything from voting to banking. Australia’s digital ID allows people to prove their identity from their device without physical documents. This feature makes it easier and quicker to request a tax file number or apply to rent a property. The UK has nearly fifty private sector organizations that are registered as identity providers under its digital identity and attributes trust framework.

Be human-centred: Put people first

Start with the individual, not the system. Digital identity must give people control over their data, letting them decide what to share and with whom. Ensure that people can see who has accessed their data and why—like Estonians can with their digital ID. We described in recent reports on digital identity how this feature can be achieved with digital credentials in the public and private sectors.

Consider applying techniques such as selective disclosure, zero-knowledge proofs and potentially even anonymous binding and standards like Solid, which put the user in control and allow verification without revealing unnecessary information. Think of it like showing a shop that you’re old enough to buy age-restricted products without revealing your date of birth, name or address.

Design for inclusivity: support people without smartphones by providing face-to-face enrollment options. Moreover, co-create the system with civil society and industry using open, transparent processes designed for the digital era.

Be secure: Protect trust from day one

A widely used digital identity system is a piece of critical national infrastructure that underpins essential services, making it a prime target for cyberattacks. Without it, people cannot identify themselves when accessing government or private-sector services, causing daily life to not function normally. One major breach could erase trust overnight.

Security must be embedded from the start. Public key encryption can provide confidentiality and integrity; the same way it secures online payments. Employ a decentralized architecture to avoid a single point of failure. It helps keep the scheme operational even if one of its systems is compromised, while also avoiding other risks inherent in creating another new, centralized, government database.

Incorporate leading identity fraud controls and robust easy to use processes for keeping data accurate—taking inspiration from industries like banking.

Resolve the paradox

Governments now have the tools to move beyond the privacy paradox and create privacy respecting secure digital ID. This ID can be downloaded to an individual’s smartphone and instantly verifies their right to drive, work, buy age-restricted items or any other government attested claim about them.

By creating flexible, human-centred and secure processes, built on the foundations they already have, they can create an identity infrastructure that serves governments, business and citizens, for decades to come.

The pilots made supply chain data directly accessible to the government, used new technologies to preserve goods’ physical integrity and considered how trusted relationships could enable certain controls to be performed by industry rather than the government.

IBM Consulting™ and Maersk led a consortium that included Hutchison Ports Port of Felixstowe, Maritime Cargo Processing, Pure Electric, Quantexa, Westbridge Foods, WM Morrison Supermarkets and other industry partners. The consortium ran a pilot that provided the government with additional supply chain data for 700,000 consignments. Through the pilots, the UK government found that novel, digital, risk-based methods for border control can provide higher quality data and could decrease decision-making time for goods entering Britain by 17%.

Models improve trade for industry and government

The report finds that the tested models can eliminate up to 62% of delays on imported goods that are subject to plant, animal or health controls. The models also reduce private sector customs data collection costs by 40%. Reducing delays increases the predictability of supply chains, which enables further optimization and cost reduction (including the reduction of inventory carrying costs). In addition to industry benefits, access to supply chain data improved government frontline targeting teams’ confidence in their decision-making, helping employees assess risk more accurately and target their resources more effectively.

Defining standards and investing in technology to realize data’s potential

To realize the potential of these models, there must be clear industry benefits to encourage voluntary participation. The Ecosystem of Trust report recognizes that to be truly transformational, the government must work to define and provide border facilitations for scheme users.

The report concludes that the models can’t be deployed at scale yet because industry cannot provide the government with the required supply chain data at scale and in machine-readable format. Furthermore, the government has not adequately determined the most effective ways to use the data it receives.

Successful adoption will require a focus on interoperability, adoption of digital trade document standards, investment in global industry platforms that can make supply chain data accessible and suitable analytics that empower the government to leverage data.

Hear more about the Ecosystem of Trust pilot led by IBM and Maersk in this video:

Read more in this Ship2Shore article (© Hutchison Ports (UK) Ltd. 2022).

Read more in this WCO news article or download as PDF.

Read more in this WCO news article or download as PDF.

This article highlights key research regarding the challenges and opportunities in creating more comprehensive national identity management schemes and key lessons that we have learnt from implementing these schemes. Such schemes are best viewed as a series of interconnected processes relating to the handling of personal data. Each process area raises different challenges. The two process areas considered in this report are identity authentication, confirming that an individual is who they say they are, and identity management, where personal data is used for transactions, or maintained and shared with others (Dennis Carlton 2008). The important processes related to identifying an individual when they are not present (such as those used for crime scene analysis) are not considered.

Impediments to progress – piecemeal pervades

IBM research indicates that very few countries have a cohesive identity management strategy (Bryan Barton 2007). Those that do are struggling to implement it completely. Working without an overall plan nations have devised piecemeal, often narrowly focused identity management approaches in response to specific national security, immigration control and other societal concerns.

Our recent experience gained whilst advising an East African country is typical:

• There is no single widely deployed system that can reliably authenticate the identity of all individuals within the country using attributes (such as fingerprints or other biometrics) that are hard to falsify.
• There is no single trusted reference number that can identify an individual from birth to death.
• Processes to issue the various documents that may be treated as identification (National ID Card, Passport, Driver License etc.) are not joined up, for example there is no linkage between the National ID card records held by the National Registration Bureau and Passport Issuance.

Towards improved identity management

Positioning pan-government identity schemes as having benefits for people (e.g. easier access to government services) as well as benefits for government (e.g. increased security) makes it easier to defend the investment and changed required to implement them. Having secured the mandate to implement such a scheme our experience highlights that they must be, trusted, available, flexible and deliverable.

Trusted

The scheme should be universal so that users trust it to identify any individual within the country. A front line government official needs to be certain that they can reliably identify an individual whether they are a citizen, migrant, visitor, asylum seeker, refugee or illegal. It must support the accurate authentication of an individual’s identity. This requires the routine use of biometrics as part of the authentication process. Biometrics are hard or impossible to duplicate or share so are particularly useful where there is a significant incentive for people to falsify their identity. Routine use of biometrics in the authentication process requires accurate automated biometric matching. Other non-biometric authentication techniques should be considered where there is a lower incentive for impersonation and where the individual is not physically present. After authenticating the individual, these alternative techniques should provide access to the same underlying personal data.

High data quality is also critical to building trust. Schemes need to establish a clear policy and confidence threshold for the identities that will be migrated into the scheme, taking into account factors such as the likelihood that the identity is fraudulent. Consideration should be given to establishing a process to automatically determine the confidence level for key items of personal data based on available metadata (data about the data e.g. the source organisation). Where necessary individuals who cannot be migrated into the new scheme should be re-registered. Furthermore a process for resolving quality issues as they are discovered should be defined to support continuous improvement. Application of data stewardship principles and other master data management techniques that have been developed in other industries such as banking will also help to drive data quality improvements.

Available

The technology that underpins the identity scheme should be open and support interoperability to ensure that its data is available for access. By their very nature these schemes cut across many government and private sector organisations and processes. Their value increases exponentially with the number of processes that make use of the scheme. Using technology that is open and interoperable reduces the barriers to automatically integrating the data managed by the scheme with other public and private sector processes.

The scheme should support mobile access out “in the field”. A key benefit is the ability for front line staff (e.g. the police) to identify an individual who cannot, or refuses to, provide any identity documents. For this to be practical front line staff must be able to routinely access the scheme’s identity information which requires the use of wireless mobile biometric identification devices.

Flexible

The organisation, processes and IT should be flexible; enabling new technologies to be introduced as they evolve. Biometric technology has advanced substantially in the last decade and will continue to do so. Identity schemes need to be able to take advantage of this new technology to deliver increased benefit; for example introducing new modalities such as iris or facial recognition or implementing multi-modal biometric authentication. Individual elements of the IT system, such as the biometric matching engine, should be able to be swapped in and out of the solution. This is key to creating a flexible IT system and places the government in a strong negotiating position with the IT vendors. Adopting a component based, service orientated, IT architecture using best of breed software from multiple vendors rather than a monolithic solution from a single vendor provides this flexibility.

Deliverable

Delivering a successful identity scheme requires a multifaceted programme of change including complex IT systems integration; modern programme management techniques should be adopted to ensure success. Key to this is to establish and communicate a compelling vision for national identity management. Then deliver this vision incrementally using the learnings from each increment to inform, and where necessary correct, the direction of future work. Well planned change management is critical to ensure that value is delivered by the new organisations, processes and systems by making sure that people are motivated, trained and incentivised to adopt the new ways of working.

One definition of a Solution Architect is that they lead the design of an IT solution that addresses specific business needs. This requires agreeing what elements of a business process should be automated and then specifying an appropriate high level design, or architecture, that will enable the IT system to meet those specific business requirements within the constraints (most commonly implementation cost and timescales) set by the organisation.

In my opinion one of the key skills is a willingness to make thought through compromises between conflicting factors and to spend time explaining the rationale for these compromises to project stakeholders. This is easiest to explain with an example and I was recently involved in a project at a large international bank that provides a good case study.

During the early part of a change delivery project a key task is establishing an estimated cost, schedule & architecture which will enable the successful delivery of the IT solution. This task is often led by the Solution Architect and generally requires making and agreeing trade-offs between the scope, cost and schedule.

Step 1: Understand the business problem and context

The Business Objective for this project was very clear. Within the next year, the bank must comply with new regulations that require the regular submission of additional data to the regulator. This additional data provides an enterprise wide view of the firm’s current exposure to different kinds of risk.

It was agreed that given the nature of the objective a key influence on the solution was that implementation time was more important than delivery of all possible scope, which in turn was more important than implementation cost.

Some information on the current Enterprise Business Architecture was also provided. It showed that the firm manages each risk type independently and that there is minimal standardisation across, or integration between, the different parts of the organisation that manage each risk type (see figure 1).

Step 2: Confirm the current state Application Architecture

After speaking to various individuals in the firm it became clear that, rather unsurprisingly, this business architecture is mirrored by the current Enterprise Application Architecture. Each department has created its own processes and IT systems to manage the risk that they deal with (see figure 2).

Step 3: Confirm the high level requirements for the IT solution

Based on an understanding of the objective, the current state, knowledge of typical bank processes and some additional information provided by the regulator it was possible to agree with the stakeholders that the candidate high level requirements for the IT solution were:

1. Submit exposure data on a quarterly basis
2. Submit the data as XML and according to a data model specified by the regulator
3. Support the reconciliation of the data to various other published reports
4. Support reconciliation between different risk types
5. Support a data validation, adjustment and approval process
6. Provide these services in excess of 99% of the time between 01:00 GMT and 23:00 GMT Sun-Fri

Step 4: Identify key gaps

The existing Application Architecture could support elements of most of the high level requirements. However it was apparent that there were two key gaps:

1. Missing data: the existing risk systems did not capture all the data items that would be needed
2. XML interface: There was nothing in the existing architecture that could submit the data as XML to the regulator

Step 5: Consider Application Architecture solution options

There appeared to be two plausible solutions. The first, shown in figure 3, was a federated solution where each risk system is enhanced with its own XML interface and sends information directly to the regulator.

The second, shown in figure 4, was a centralised solution where each risk system feeds data to a new centralised database. In turn this database can provide data to a single XML interface that sends information to the regulator.

Step 6: Evaluate the solution options

The key insight in the evaluation was that the cost, complexity and risk of the solution lie primarily in closing the data gap. The cost of building a component to submit the data as XML was likely to be insignificant compared to this.

The centralised architecture could meet all the high level requirements. However because it introduced a completely new IT system it would require a significant system integration test phase to confirm the correct integration between the existing risk systems and the centralised data store.

The federated solution could not meet the requirement to support reconciliation between different risk types. However it is a simpler solution and did not require such a significant integration test phase. For this reason the risk of missing the implementation deadline with the federated solution was lower than with the centralised solution.

Given that implementation schedule had been rated as more important than scope or functionality the recommended solution was therefore the federated solution. As always reaching this conclusion was relatively simple when compared with the process of getting all the stakeholders to agree that it was the correct decision.

Step 7: Create an estimated cost & schedule

Once the solution architecture was confirmed we could start the process of estimating the cost and schedule. The schedule was derived by seeing that since there we no interdependencies the enhancements to each risk system could be delivered in parallel. Once this decision was made the schedule could be estimated by considering reasonable durations for each of the standard project phases.

Given that the solution enhanced existing systems there were no costs due to hardware or software licenses. Hence the delivery cost could be estimated solely by estimating the number of people required to deliver the changes to the IT systems.

As you can hopefully see no rocket science was required, however it was necessary to follow a logical approach to the decision making and also to be willing to take time explaining the rationale behind the recommendation.

Over the course of my career I’ve witnessed several different approaches to this problem. In my opinion the framework that has proved most effective is one that was developed by PwC, called the The Seven Keys to Success. I’ve seen it used, on many different occasions, to communicate difficult messages to senior managers up to and including board members.

The Seven Keys To Success are applicable to any kind of project that you can imagine. It works by assessing the project across seven different critical success factors that resonate with executives and by focusing on the action that you wish them to take:

You can read more in the original 2002 whitepaper.

One of the key tenets of all Agile delivery is to deliver early and deliver often. Whatever you think about using Agile to deliver IT projects in complex organisations it is worth understanding one of the key rationales for this mantra.

Imagine this common scenario in a project steering committee. A stakeholder has submitted a change request for the project. The project team have rapidly turned around an impact assessment which indicates that it will mean delaying the go-live by 2 months to allow for the new functionality to be developed and tested.

How should the committee decide what to do? A common response to this will be to look at the additional delivery costs that this two month delay will be incur. If funding can be found to cover this then the change request is approved.

However what this has ignored is the cost of delaying any realisation of benefits by an additional two months. A sign of a healthy project with a robust benefits case is that less focus is placed on the cost of delivering the project and more emphasis is placed on when the solution will be delivered.

The graph below shows why this focus on timescales is important to the organisation as a whole. It shows two different ways of delivering the same project with the same benefits case. Approach A goes live earlier than approach B but costs significantly more to deliver. However, you can see that it still breaks even earlier than approach B because it started realising benefits earlier.

Agile delivery takes this concept to the next level by “timeboxing” releases of a project. This means that the project team commit to go-live on a particular date. In return other stakeholders commit to the principle that, if necessary, scope will be pushed from that release into subsequent releases in order to hit this date¹. Doing this ensures that the organisation can start realising some benefit from its investment as soon as possible.

Even if you aren’t working on an Agile project, the next time you’re next asked to look at a change to a project’s timescales have a think about what the impact of delaying the benefits realisation might be.