Do you even need digital identity?

When designing public services online, many organisations instinctively start by placing a digital identity solution in front of it. In this post, we explore why you should first ask “do we even need digital identity here, or is there another way?” We’ll also look at alternative approaches you can take, and finally, why identity verification is not a once-and-done activity.

When you might need identity

For a service provider, digital identity is a tool to help manage the risk that someone is not who they say they are when they’re trying to access data, money or services. But the impact of that risk exists on a spectrum. Serving the wrong user could lead to significant financial losses, or even a risk to life. At the other end of the spectrum could include a service where you need to pay government money. Your bank wants to be sure it's you, but the government doesn’t mind who pays off your tax bill and it's unlikely someone would be doing this for fraudulent purposes.

So one of the first steps to take when thinking about and designing a digital identity service is to understand your service landscape. Are you building something for a group of services that will all need the same solutions, or are you building for a range of services with different risk levels?

Having a one-size-fits-all digital identity solution may well create unnecessary barriers to services and increase exclusion. For example Uganda requires fingerprints to register for an ID card that is used to access a range of essential government and banking services, or even start a job. However, people who are unable to present their fingerprints due to a disability are left unable to access these services, many of which on their own would not require fingerprints.

Other ways to secure your service

If the users don’t need to verify their identity (which will also make the service team’s life a lot easier!) then what are the other options? There are a range of tools which can be used against certain fraud and cyber security risks related to user access. IP address watchlists, CAPTCHA tools, one time codes, magic links, anonymous checkouts are just some examples. (Obviously each of these approaches has strengths and weaknesses, for instance CAPTCHAs have accessibility issues.)

Just the right amount of assurance

In the UK the Driver and Vehicle Licensing Agency (DVLA) uses a range of approaches to access different services that have different risk profiles. For example, to view the details on your own driving licence in the UK you need to provide three key pieces of information that help DVLA find the right record and give a level of assurance that you are the right person trying to access this information (picture below). While this information is sufficient to allow this “viewing” transaction, it’s unlikely that the agency would then allow other transactions to take place without further checking. This data identifies the right record, and the knowledge of that combination provides some evidence that the person accessing it is that person, but does not definitively prove that the person accessing the service is the right person. This design will have been based on a clear understanding of the risk and potential impact, as well as an understanding of user needs and capabilities, to determine the right approach.

Prevent vs. detect

Considering the wider question of whether you need to prevent fraudulent transactions from starting, or can detect and clean up later, may help you decide your approach. Trying to prevent fraud at any cost can unnecessarily deter people from engaging with the service. Again this is about understanding the risk and potential impact of not knowing who your user is, but it's also about recognising the impact of your approach and whether that is the only way to secure your service.

For example, many governments around the world, including the UK, Australia, New Zealand, Germany, have created a way to create and sign online petitions that the government has a duty to respond to. You would like to be confident that the person signing the petition is who they say they are, but the impact of them being someone else at an individual level is quite small - the data collected has errors in it, embarrassing for that individual if it is shown they signed a petition they would not agree with. The downside of putting a complex and time-consuming digital identity journey onto the front of that service would not be balanced against the risk. The greater risk is from bad actors attacking the service on a much larger scale (e.g. hundreds of thousands of signatures that are not real) either to skew the results, embarrass the government or to try and take the service down. The better approach in this case is likely to have tracking and alerts set up to detect when such attacks are taking place and then respond.

​​Make sure you're having the right conversation with your security team. Make sure you're all on the same page, and concerned about the same problem. Don't start with identity, talk about the risks to the service.

Authentication versus identification

Many services do need a secure sign-in process but don’t need identity verification at all, or don’t need it yet. Login.gov is a good example of a layered approach. It is a secure account that allows you to access all federal services with one set of credentials, many of which do not need identity verification.

If a service does require actual verification of identity then you can use login.gov to do so. That verified ID can then be stored and reused for other services. The UK Government Digital Service is also approaching identity and authentication in a similar way right now.

Levels of identity verification

For other scenarios you may need to build different levels of identity verification for different services. Some services may need one piece of documentary evidence and the answers to questions based on personal information only the user would know. Other services may require verification of biometric details.

Public services should be accessible, so do not require the strongest digital identity until you are dealing with your riskiest transaction. Otherwise you will leave a lot of users and services out.

You have to keep asking this question throughout the life of a service

As long as your service is being used, there is a need to keep asking the question, “do I need identity verification?” at regular intervals. As your service grows, your user base and the complexity of interactions you can deliver increases, and so the risks around identity and securing your service against fraudulent users will change.

Tools that have been used in the past to verify a user may no longer be appropriate. For example in the UK, the National Insurance Number has often been used in the past to verify identity. However, the way it is used now by employers and other organisations means it’s no longer a secret that only the individual knows.

Trust and confidence in a user's transactions can degrade over time, or require increasing for more risky activities. You may also add in more complicated transactions that mean you need to look at those security assumptions again. On the flip side you may also have more data about what “normal” looks like to better spot fraudulent activities.

When designing public services online, many organisations instinctively start by placing a digital identity solution in front of it. Our advice is to question that assumption, consider what your risks around identity and user access are, and keep checking in over the lifecycle of the service.