Using citizen IDs for commercial services will take an identity ecosystem

Citizen identity systems like the UK’s Verify initiative are costly. It only makes sense to offset that cost by allowing commercial entities to utilize citizen IDs. Here's what it will take.

identity concept 164551610
Thinkstock

I was heavily involved in the UK government Verify scheme for several years. It was a challenging service to build as the government designers behind the initiative had a very specific set of challenges. First, they had to design for the type of wide demographic represented by an entire country. At the same time, the service had to be secure from fraud. This was, and is, a fine balancing act. It takes the usability vs. security debate to a whole new level.

Identity theft is a scourge of modern times. Javelin Research on identity theft and fraud has reported some interesting changes between 2017 and 2018. Although the overall number of victims decreased in 2018, mainly due to a decrease in card fraud, there was an increase in accounts being opened in victims’ names. As someone working in the field of identity management, this concerns me greatly. The true cost of online impersonation has only just begun to be realized, and the industry needs to build bridges to stop this, now.

I believe that a way forward is to bring together the knowledge that government and commercial services, like banks, already have.

What have we learned from citizen identity?

Governments need to allow their citizens to access government online services to keep up with technology changes, reduce costs, and meet citizen expectations. But many government services have a high value. Online tax services, for example, have already been victims of fraud. A look at the IRS ‘dirty dozen’ list of scams used to defraud the U.S. tax system shows what they are up against.

Getting that heady mix of “identity for all” within a hardened identity framework is no mean feat. The UK government’s attempt at doing this has been heavily criticized. The UK’s National Audit Office (NAO) published a report that looked at the shortfall of Verify. These shortfalls are mainly a mix of cost (always an issue for government) and ‘match rates.’

Match rate refers to the ability to ‘verify’ an identity. Verification, in the case of Verify, and other government identity services, means using third-party services, like Credit File Agencies, and ID document checking services, to check an individual. The output from these verification checks, along with the credentials used to authenticate the individual, determine the level of assurance (LOA) of that person.

In the case of Verify, there were two levels that could be achieved, LOA1 and LOA2.

The idea of levels of assurance is not confined to the UK government. NIST originally came up with 4 levels of assurance but recently retired this concept. This is what NIST says in Special Publication 800-63, Digital Identity Guidelines:

Rather, by combining appropriate business and privacy risk management side-by-side with mission need, agencies will select IAL, AAL, and FAL as distinct options. While many systems will have the same numerical level for each of IAL, AAL, and FAL, this is not a requirement and agencies should not assume they will be the same in any given system.

IAL, AAL, and FAL are verification, authentication, and strength of federated assertion, respectively.

NIST, in my opinion, are very sensible in doing this, but could have gone further. I have always argued that strict LOA is based on a highly prescriptive set of requirements that are not flexible enough to service modern ID needs.

The reality is that LOA is only a subset of an identity and it’s the underlying attributes that are needed to do online jobs.

This brings us to how citizen ID, made up of often static, inflexible Levels of assurance can be molded to the needs of modern consumer-centric commerce.

How LOA is part of doing online tasks

Verify was (and is) a costly exercise for the UK government to bear. One of the ways of offsetting this cost is to allow commercial entities to utilize citizen IDs created under the scheme. Makes sense. If a user is able to get a Verify identity or any other government identity, they will have been through a tough user journey.

However, commercial organizations have their own, unique set of needs. Simply having an LOA and associated attributes may not be enough.

A bank, for instance, will need their own set of KYC/AML checks. If a person applies for a financial product, an LOA wouldn’t have the right financial data to complete the task. If a person applies for a job online, a government identity wouldn't have professional certifications embedded.

I could go on, but you get the idea.

LOA is a useful guide to the verification status of a person, but it is only one part of the data needed to transact. At the same time, over 4 million UK users have a UK Verify identity. It would be a crying shame to not take advantage of these already verified identities.

In this case, LOA can be thought of as its own attribute and can be used to build friction-reduced, but with assurance, identities.

In hub we trust

The trick is in how you use the government identity. Most of them are based on the SAML 2.0 protocol, although some will move over to OpenID Connect at some point. This means that if you want to use the government identity for your commercial service you need to consume that protocol. In addition, the ‘flavor’ of the protocol may not fit in with the expectations of your service.

The use of verified IDs and other identity accounts can be used by commercial services, but it has to be part of a wider ecosystem. The days of siloed online identity are numbered and are holding us back.

Having your identity cake and eating the attributes can be afforded by going back to the idea of an extended identity ecosystem. A hub or proxy is a component of the wider identity ecosystem that provides the switch to connect up the relying party services and the other parts of the system, like the identity providers. For example, a government identity could be pulled into a banking system through a hub, with the hub translating the government identity for the bank service. The bank may still need some specific attributes, but the verified government identity provides a good backbone and can even help to reduce the friction in creating an online bank account.

Conclusion

Governments have been at the forefront of verified identity systems. They have designed IAM with wide-demographic users in mind. But they have also had to finely balance anti-fraud requirements. Governments cannot afford to junk their identities and instead need to allow their reuse in a commercial setting. A direct use case may not always fit the needs of commerce, but a hard-won high level of assurance identity can help to augment the online identity and data needs of commercial services. It makes sense to look at ways to facilitate the use of government IDs in commercial settings, but we need to consider LOA as an attribute in its own right rather than representing a digital identity in its own right.

Copyright © 2019 IDG Communications, Inc.

Get the best of CSO ... delivered. Sign up for our FREE email newsletters!