Gov.uk Verify and identity assurance - it's time for a rethink

Business case

The original business case for building the Gov.uk Verify platform relied upon the reasonable assumption that major departments, such as HM Revenue & Customs (HMRC), would make extensive use of it. However, HMRC has suggested that it will proceed instead with an earlier, alternative approach based around enhancing the existing Government Gateway service – which supports not only citizens, but intermediaries and businesses too.

Gov.uk Verify is displaying the worrying and familiar symptoms of a troubled government programme

Despite its original worthy aspirations, Verify is displaying the worrying and familiar symptoms of a troubled government programme. It’s running significantly behind schedule and de-scoped, and possibly over budget - although this is difficult to determine since, as the NAO report noted, “…before 2016-17 GDS did not split its staff costs into specific programmes”. Verify’s lack of support for anything other than basic citizen authentication - a small subset of known user needs for online services - means it offers no clear transition path from what is already in place.

It’s worth remembering that what we refer to as “Verify” is at least two things: an online identity assurance framework that establishes trust across private and public sectors; and the physical Gov.uk platform built by the Government Digital Service (GDS). The Verify framework is all about developing consistent, interoperable standards of trust, security and privacy across public and private sectors. However, the poor track record of the physical Gov.uk Verify platform is in danger of torpedoing the significant potential benefits that a trusted identity assurance framework could bring to the UK economy.

So why has Verify ended up in this confusing state – and how might it be fixed?

The timeline

In May 2011, Francis Maude, then minister for the Cabinet Office (MCO), expected implementation of Verify to happen in August 2012. This date came and went, and several more years passed. When the NAO recently reviewed the progress of the Verify platform it found numerous missed targets.

“In 2014, GDS expected over 100 departmental services to be using Verify by 2016. In October 2016, GDS predicted that 43 services would be using Verify by April 2018. In February 2017, 12 services were using Verify. None of the nine services that were in the pipeline for connecting to Verify during the remainder of 2016 was ready to do so by that date,” said the NAO report.

Verify formally entered live service in May 2016, having appeared as a beta service in October 2014. By the time of its live implementation, Verify was nearly four years behind schedule and working with just 12 services. Most of these 12 services also offered alternatives to Verify.

As the NAO report commented: “Nine of the 12 services using GOV.UK Verify can now be accessed using both Verify and a department’s chosen way of allowing users to log-in to services. This parallel access undermines the current business case and risks creating confusion for service users.”

Far from helping improve the user experience of online services, Verify’s failure to provide trusted identity assurance across government services has resulted in the fragmentation of the user experience – the very opposite of what it originally set out to achieve.

The NAO report observed: “To achieve the target of 25 million users by April 2020, GDS needs the profile of users to increase at a much sharper rate from April 2019. The September 2015 business case predicted 4.4 million users by the end of March 2017. This projection was reduced to 1.8 million in the October 2016 business case. As of February 2017, Verify had 1.1 million user accounts.”

Poor discovery

Neither the Gov.uk Verify platform or the desire for a cross-sector identity assurance framework were created on a blank page. They had the significant advantage of entering an existing services environment where many lessons had been learned about online identity. Since 2001, for example, the Government Gateway has provided the primary means for users to authenticate themselves to a wide range of online government services, from self-assessment to the state pension forecast.

As the NAO report notes: “[The] Government Gateway currently hosts 138 live public sector services, and the Gateway is being improved. GDS has not reassessed the cost and security implications of an improved Gateway service.”

The Government Gateway was designed, like Verify, as a federated identity hub – as Mike Bracken, the former boss of GDS, acknowledged in November 2011 in a blog post titled Establishing trust in digital services. The Gateway was created to support a marketplace of trusted third-party identity providers who would carry out the process of identifying and authenticating users, and manage their credentials. For this reason the Gateway supported not only its own user IDs and passwords, but also third-party digital certificates and chip-and-PIN cards, using open standards such as SAML and W3C digital signatures.

Most of the problems with delivering the Gov.uk Verify platform are indicative of an apparent failure to follow GDS’s own guidance. In particular, a failure at the discovery stage to understand what had previously been tried (and failed), what was already in use (both good and bad), and what user needs Verify would have to meet if it were ever to become a viable means of large-scale user identification and authentication. However, there appears to have been little or no systematic attempt to understand the existing landscape. As a result, it lacked the necessary situational awareness.

HMRC, for example, has made use of the Government Gateway’s identification and authentication services – for citizens, intermediaries and businesses – since 2001. Both HMRC and other departments have learned a lot about what does – and doesn’t – work when it comes to online user identification, authentication and verification, and the related problems of data-matching, in the intervening years. As a result, there were already many important insights and lessons the Verify platform team should have tapped into, enabling them to accelerate and focus their efforts, and avoid repeating the mistakes of the past.

Use of APIs

HMRC and others also make extensive use of application programming interfaces (APIs), which let computer systems talk to each other, to interact with the outside world. It is unclear whether Verify works only for users logging into online government websites, or whether it can also be used where an external system needs to interact with a government department programatically. Existing Government Gateway APIs enable, for example, employers’ payroll and accounting services to make secure submissions to government signed with the user’s credentials, and to receive responses.

This apparent lack of focus on how Verify can be used with APIs for interacting with government services is surprising. APIs were a principal recommendation of the original Martha Lane Fox proposals (PDF) in her 2010 report that brought about the creation of GDS. The associated executive summary included a target that 50% of government services should be served by third parties via APIs by March 2012.

However, the recent 2017 NAO report found that: “GDS has only recently published guidance on using application programming interfaces (APIs) to link administrative systems, despite an emphasis on APIs when GDS was first set up.”

It remains unclear why Lane Fox’s recommended implementation of APIs across government for third-party provision of services didn’t happen. The emphasis instead seems to have been on front-end, website-based development instead. There is still no timetable for the opening up of APIs despite this being a key outcome set out in Francis Maude’s response to Martha Lane Fox, and its relevance to making better use of data.

Among the discovery steps described in GDS’s own guidance, the Verify progamme seems to have skipped at least the following:

• You should find out … your users’ needs and how you’re meeting them, or any needs you’re not meeting
• Which services currently meet your users’ needs and whether they’re government services or private sector
• How you’d start developing a new service if your discovery finds there’s a user need for one

Even within the subset of user needs it does propose to meet, Verify continues to experience significant problems with citizens’ initial registration and their subsequent re-use of their account(s). These problems are likely to be worse for those who do not have “recognised” or “acceptable” official documentation such as passports or driving licences, or other “established” forms of financial status – exacerbating existing problems of digital social exclusion from often essential public services.

Verify’s notably slow development and implementation is particularly surprising given it only tackles a subset of user needs. Yet after six years it’s struggling to meet even these simplified and de-scoped needs. This compares particularly unfavourably with the Government Gateway which was designed, built and operational in live service in just 15 weeks – despite meeting a demonstrably larger suite of user needs than Verify. It’s another reason why it lacks credibility with departments.

This slow progress with delivery and the continuing lack of functionality suggests a poor use of the agile processes recommended by GDS. When applied well and with discipline and rigour, agile can enable rapid delivery of functionality at both pace and at scale.

Given the Gov.uk Verify platform team had the advantage of tapping into all the experiences of federated identity and cross-departmental identity requirements accumulated across government and the private sector since 2001, it’s unclear why the Verify platform has ended up running so late and de-scoped.

The danger is that all of these problems with the physical Verify platform will undermine the more important work that aims to develop and establish a trusted identity assurance framework. It’s important that these two aspects are kept apart when considering “Verify” – it would be a major opportunity lost if moves towards a successful framework that spans public and private sectors were lost because of difficulties with the poor scoping and performance of the Gov.uk Verify platform.

Verify and federated identity

Federated identity usually involves using an existing trusted relationship to prove who you are to another party – such as when we use a UK passport to prove who we are when crossing a border; or a chip-and-PIN, or contactless, bank card to authorise payment to a retailer.

The original idea behind the Verify identity assurance model was that we should be able to prove who we are online when using government services using a trusted third party with whom we already have an existing relationship. For example, you turn up to do self-assessment online and prove who you are using a chip-and-PIN card issued by your bank or building society. A good, simple user experience (if we set aside the notable problems of reliable data-matching for a moment).

This is not what Verify currently does – and where it diverges from a trusted identity assurance framework.

Verify requires citizens to establish a brand new relationship with a commercial organisation with whom the citizen has no prior relationship - and probably no particular desire to have such a relationship. In creating this imposed relationship with a chosen commercial provider, the citizen is obliged to disclose a wide range of personal information. Such data include for example some or all of:

• full name
• date and place of birth
• full postal address
• email address
• telephone number
• passport number
• driving licence number
• marriage certificate
• birth certificate
• bank account details
• type and numbers of credit cards held
• mortgage details
• length of time at current address
• loan details

If a citizen gets through this whole process successfully, the commercial provider will maintain the citizen’s credential - typically a user ID and password. This new commercial provider now controls a user’s online authentication and access to government services.

This approach is not the one originally envisaged for the identity assurance framework. The original idea was that citizens should use a trusted third party with which they already had an existing relationship – and which could therefore provide assurance about their identity.

Instead, an artificial marketplace of commercial entities has been nurtured and paid for by the Verify platform. These new third parties have effectively been given an exclusive mandate as commercial gatekeepers of citizens’ access to online government services.

This approach also breaks one of the sensible “laws of identity” set out by Microsoft identity architect Kim Cameron many years ago. It inserts a brand new third party between citizens and government which has no obvious place in that relationship. Given all the political sensitivities about “privatising public services”, it’s unclear when the Verify platform team made the decision to insert and mandate commercial organisations as the monopoly controllers of authenticated citizen access to online public services.

In its current approach, the Verify platform has either by intent or by accident resurrected a mandatory sort of Microsoft Passport for government services. It has artificially inserted a new commercial organisation into the relationship between a citizen and their online government services, requiring citizens to hand over a considerable amount of personal information to third parties in the process.

Given that this was not the original vision or intent, it’s important to get the work on a trusted identity assurance framework back on track.

Policy questions

The government is understandably keen to promote the increased use of online services. Establishing a credible, reliable and trusted identity assurance framework that can work across private and public sectors, and enable us to prove who we are online, is an important ambition. Getting this right is a precursor to many other important developments, such as being able to get access to and control over our personal data – and to protect it from unauthorised or fraudulent access.

However, the physical implementation of the Gov.uk Verify platform and the aspirations of the work on an identity assurance framework seem to have drifted apart. The Cabinet Office’s Privacy and Consumer Advisory Group (PCAG) has aimed to ensure that the extensive and detailed personal information required by the commercial providers contracted by Verify cannot be misused, through the Identity Assurance Principles (PDF). However, the design and associated commercial arrangement raise numerous and significant policy questions about the Verify approach, including:

• Why and when was the policy decision taken that online government services requiring authentication can only be accessed by citizens via a commercial company with whom the citizen has no prior relationship?
• Why are commercial organisations being paid to vouch for “identity” when many of the checks they carry out, such as validating passport and driving licence numbers, actually use services that government itself provides and which it can use itself without any payment?
• What happens if a citizen refuses to hand over their personal data in order to use one of those commercial service providers, but still wishes to have access to online government services? Will they be unable to use online public services?
• What happens when a commercial provider exits from the Gov.uk Verify marketplace? Will a user have to start from scratch and go through all the same data-invasive and departmental data-matching steps again with another company?
• Given that departments and other public sector organisations still need to carry out their own assurance checks to match citizens accurately to the right records and data, what additional value is currently provided by the third-party identity providers?

The true costs are unclear

The charges imposed by the commercial providers for Verify have not been made public due to issues related to “commercial confidentiality”. However, informally people close to those running the services, both inside government and at the commercial providers, indicate that the charges made by the companies range from around £9 to over £20 per user.

At the moment, departments and other organisations using Verify services are having their costs heavily subsidised by the central budget GDS secured for the current spending period. As a result, they contribute only £1.20 per successful confirmation of identity per user per year, regardless of the actual cost to the taxpayer.

It’s unclear what will happen if departments and others using Verify cease to have their costs centrally subsidised in the future – as implied by the NAO report, which said: “Verify is expected to become self-funding in 2018-19. Of the £53m decrease in GDS’s funding between 2017-18 and 2018-19, two-thirds (£36m) relates to removal of revenue programme funding for Verify.”

If this is the case, public sector organisations planning to use Verify must allow for significant additional costs from their own budgets as the central subsidies are reduced or entirely withdrawn. Based on the rumoured actual costs of Verify, this could be anything between seven times and 17 times, or more, than the £1.20 they currently pay.

Behind schedule – and a poor user experience

Some six years since its inception, the Gov.uk Verify platform is struggling to establish itself as a viable service. This failure is having knock-on consequences. According to government insiders, Verify’s poor performance and lack of departmental buy-in is undermining the more important work underway to establish a trusted identity assurance framework able to work across both private and public sectors.

Meanwhile, many users’ experience of Verify remains poor, and they fail to prove their identity to the commercial providers. Verify’s own performance dashboard shows that just 55% of users succeed either in creating an account, or in re-using an account they have already created. The service dashboard reveals that only 44% of those users then “successfully access a service, following the creation or re-use of a verified account with a certified company”.

If these figures are correct, it implies that of the 55% of users who actually manage to create an account only 44% of those then successfully access a service. Does this mean only around a 24% overall success rate - that only 44% of the 55% of users who create an account are successful? It would be easier to understand the true situation more clearly if the published data were clearer – and did not bundle multiple aspects, such as “creating an account, or re-use of an account”, together into the same statistic.

Despite these figures, the Verify team remain optimistic and claim it will be mainstream by 2020 – the government transformation strategy set a target of 25 million users. This will be 10 years after the programme started, and after many similar repeated promises of imminent success. By 2020 Verify will be older than the “legacy” Government Gateway was when the Verify programme started and, based on current plans, still lacking essential functionality.

Time for a reset

It’s time that the Verify platform, other “competing” initiatives such as the updated Government Gateway, and the underlying work on an identity assurance framework are subject to an open, honest and fundamental reset. A significant amount of money, time and resource have been sunk into the Verify platform in particular, but without delivering the results desired or the success repeatedly promised.

The NAO report set out a series of high-level recommendations for the Gov.uk Verify programme, emphasising the importance of establishing a clear case; adequate early analysis or “discovery”; and a consideration and assessment of options.

GDS needs to follow the principle of “physician, heal thyself” and rigorously apply its own guidance to itself – from a fundamental and honest re-appraisal of user needs and a thorough (re)discovery process, through to a fundamental review of the original business case and the assumptions it made.

It’s important that the opportunity for a trusted identity assurance framework that spans private and public sectors is not lost on the back of the problems facing the Verify platform. If the Verify platform were a departmental programme, it would likely have failed the GDS spend controls implemented by Liam Maxwell when he was government chief technology officer.

GDS needs to apply the same discipline to its own programmes that it expects of others. This type of delayed and de-scoped programme is a world away from the welcome vision of improvement and success that GDS once promised – and is certainly not providing world-class digital products that meet people’s needs.

During this reset, government should look to:

• Revisit the fundamental question, “What is the problem we are trying to solve and how best might we do it?”
• Revisit its identity assurance policy requirements, including whether it is appropriate for Verify to mandate commercial third parties to (a) be the exclusive gatekeepers of access to online government services and (b) the controllers of users’ credentials
• Undertake a full discovery of user needs, including those previously neglected, missed or overlooked
• Thoroughly map all existing identity initiatives and technologies across both government and the private sector, and then plot these against user needs to identify matches and gaps
• Consult on and define a clear, cross-sector identity assurance strategy and related standards - work which needs to integrate closely with a related, but currently absent, data strategy and set of standards - including analysing the impact of various options on digital social exclusion
• Validate and ensure that any proposed identity solution will be able to work with APIs as well as browser-based services
• Undertake a full, and public, privacy impact assessment (PIA) of alternative options, and involve the Cabinet Office’s Privacy and Consumer Advisory Group closely in oversight and feedback on proposed options and solutions
• Bring together key players such as HMRC, GDS and other public and private sector bodies to openly explore existing services and best future options (without getting hung up on the various favoured projects already in play), including short-term and longer-term costs
• Apply the principles of “cloud first” and “buy before build”, exploring how the identity assurance framework might be better and much more quickly delivered via commodity cloud-based identity-as-a-service (IDaaS) options, rather than continuing bespoke work on in-house pet projects
• Consider separating the creation and control of users’ credentials from the identity assurance processes operated by the third-party commercial providers. Management of credentials has become a commodity service in the cloud, as illustrated for example by Kim Cameron’s work on the “identity experience engine”. Government could allow all users (citizens, businesses and intermediaries) to manage their own credentials, either via an IDaaS and/or the updated Government Gateway service as enhanced by HMRC, removing third parties from controlling users’ credentials while still being part of an overall trust framework
• Consider the benefits of moving the online identity proofing service provided by the Verify platform third parties elsewhere in the process. If external identity proving is required by a public sector organisation it should only take place when needed by a service owner rather than being placed right up-front
• Review whether the hub-based approaches employed by both the Government Gateway and Verify platform, with the known security and privacy concerns of hub-based models, could be superseded by more secure technical solutions
• If desired, keep the overall Verify brand. Use it for whatever comes out of the discovery, reset and redesign process

Francis Maude, when he was minister for the Cabinet Office, used to comment that becoming a “prisoner of sunk costs” – throwing more money at a problem solely because a lot of money has already been spent on it – is almost always a mistake.

Making the hard decision to do a fundamental review and reset of identity assurance and the various competing approaches and platforms is the right thing to do. The viability of online services and establishing digital trust between public and private sectors is dependent on getting this right. It would also represent a welcome return to GDS’s original principles of working in the open, being transparent, and learning from mistakes.

We urgently need to see credible leadership and a viable strategy in this essential area. It’s important for the future of online services that government helps nurture a robust, trusted, secure and viable approach to identity assurance that can work right across our digital economy. So it’s worth making time right now to do an honest, open and public reset to get this right – returning to GDS’s idealistic first principles of delivering world-class outcomes that meet people’s needs.