How to control your biggest risks in digital identity

We recently wrote about six questions you should ask on a digital identity programme. In this post we’ll explore one of those questions by discussing some of the risks that digital identity programmes in government may encounter, and some strategies that have been used to control them. A programme to implement a digital identity service for your jurisdiction can unlock lots of value, either by replacing costly manual or face-to-face services, or enabling new services that were not previously possible. By “risks”, we mean the likelihood that your programme fails to deliver its benefits, more than technical, security, or fraud risk.

Risks in digital identity

It takes a long time to reach agreement across many parties

Public digital identity programmes have large numbers of users, public services, and identity attribute services with different needs and requirements. Creating something that both works for users and meets the needs of a wide variety of services is not a simple undertaking.

It can take many years to reach agreement on technical and identity standards, liability, and other policies. For example, the Digital ID and Authentication Council of Canada (DIACC) have spent 4-6 years carefully working to produce a comprehensive framework covering these agreements across all sectors, which are now being tested. The Australian government started the process of creating a framework for agreement in 2015, and this year they have accredited the first private sector organisation to be an identity exchange operator.

Growing a service’s market is hard

Identity programmes often need to fill a supply/demand gap in a marketplace, needing to persuade both users and service providers to join their identity ecosystem, rather than use existing or alternative services. This can be true whether the service is centralised, federated, or completely decentralised.

This means that often, digital identity services take much longer to scale than originally planned. Without sufficiently attractive and useful services onboard, the case for signing up may not be clear to citizens, and without sufficient volumes of verified users, service teams may not see the value in the identity service, and may wait for growth. Without sufficient uptake, for new services, the work required to make services truly self-service based on the trust in the identity, can be harder to justify.

For example:

• New Zealand’s Realme verified identity system had less than 20% of the forecasted uptake in the first 6 years, due to relying parties taking longer than expected to integrate the service

• In the UK, the GOV.UK Verify scheme signed up only 22 services in the first 6 years of operation, verifying the identities of approx 8M users in that time, rather than the originally predicted 25M.

• British Columbia has a very high penetration for the BC services identity card with over 4.7M cards issued (from a population of ~5M). However there is still great unmet potential for the digital offering. Since 2018 approximately 30 out of hundreds of services have onboarded to use the digital version.

Underestimating the impact of exclusion

There is a risk of underestimating the effort and the cost of ensuring that your identity service does not exclude anyone.

Digital exclusion is a common experience and it can happen to anyone. All digital services have an obligation to consider how to minimise barriers for their users, however, there are specific challenges around inclusion for digital identity. There is already an intersection between exclusion from services and the ability to prove identity, and as more evidence traditionally used to verify identity moves online, this may be growing.

On top of this, where digital identity serves a public sector need, the service typically cannot choose to ignore these barriers because they will need to reach and serve all citizens. Related, providing services that are properly inclusive often requires the creation of support mechanisms, either face-to-face, via video or telephony.

Choosing between complexity and control for users

Many capabilities are needed to manage identity governing trust, authentication, privacy, personal information, security, with a competing raft of technical standards and protocols, and there are many complicated edge cases. A good service will keep things simple for users and hide that complexity, getting out of the way of users who do not want to have to deal with these concerns.

But there is a tension - identity principles typically dictate that the user should be in control of their identity, always providing consent when their identity information is being used. So, controls must be provided, but care must be taken not to overwhelm users with choice or repeated requests for consent, in particular where users are less digitally confident. This may also limit the ability for services to usefully share data in support of the user when things change.

But some users may not care about this when it comes to government services. The risk is that you may fail to understand where your users want to be on the spectrum from being in total control, to the convenience of having someone manage everything for them.

For example, if the identity system is self-sovereign, where the user typically holds their identity in their own secure digital “wallet”, and the information is completely decentralised, users have very high levels of control of their data and how it’s used. However, with that comes greater responsibility, for example - if someone loses their wallet, they need to have a means to recover it. There are technical solutions to this problem but they may be less easy for users to understand than in a more centralised system, where it’s clear who to call when things go wrong.

We would always recommend that any digital team uses Internet era ways of working, but there are several things that identity programmes have done which help with the risks discussed above.

Start with a smaller ecosystem

Many successful approaches to identity control the level of complexity by limiting the initial size of the ecosystem of services and identity providers. The Australian government, for example, controlled the growth in complexity by choosing to solve the problems within government first, and build success there, before attempting to involve the private sector.

The Scottish government decided to focus initially on enabling users to maximise the reuse of their trusted data across services using existing relationships in the public sector. Their aim is to build success in this smaller ecosystem first, rather than tackling the private sector opportunities at the same time, and the programme has put verification of identity itself further down their roadmap.

Start with an easier user journey to build scale, and add as you learn

Identity verification and authentication are separate concepts, and many services have successfully controlled complexity by offering a strong digital credential first, adding identity verification as an additional service later.

For example the team behind login.gov, which has over 30M users across 200 services (Oct 2020) in the US General Services Administration started with an authentication service, following up with adding identity verification.

The UK government have started their new single login programme with a sign in service, planning to add identity verification as they learn more about user and service needs.

Work on both the supply and demand side

Successful programmes design for the needs of users first, then for organisational convenience. However, with identity spanning multiple services, the only way of ensuring a good user experience is for identity programmes to work closely with the teams providing those services to understand their needs.

This can encompass making it as easy as possible to technically integrate with your service, by using open standards, clear documentation, sandboxes and examples in the open. Also by making it bureaucratically simple to get started by eliminating procurement and setup costs (e.g. with the UK government’s payment platform). Finally working with service teams to help them understand how and when identity is best integrated into each user journey, for example by sharing and pooling user research.

Build community

This is no substitute for direct research with users to understand their needs, but successful approaches often involve intense work to build consensus with stakeholders on problem solving, or getting closer to groups of users and experts.

This can be in the form of engagement with privacy stakeholders and industry associations. A common approach is to use the generation of a trust framework as a focus for conversation and agreement, and as a means to bring people in and understand their concerns and needs. Focusing stakeholder attention at the level of a trust framework allows you to discuss and agree what is important, agnostic of technology or vendor, and this approach has been used at scale for identity in Australia, UK, Europe and Canada.

Make sure you can learn and iterate rapidly

It’s important to put yourself in the position where you can test your riskiest assumption with users as early as possible. This means that you may need to organise your program so that the aspects you are least certain about, are in a position where you are most easily able to learn and change.

Successful programmes keep development of the parts of their service they are least certain about close, putting them in the hands of teams they are sure are able to learn and adapt quickly. For example, the General Services Administration in the US decided to build login.gov in-house in 2016, which enabled them to closely control and iterate the whole user experience more easily, replacing previous federated systems that had multiple parties, although this move was not without controversy at the time.