This is part 3 in my occasional blog summarising the past 20 years or so of UK efforts to move government online. The previous parts provided summaries on progress towards a single online presence and a similar high-level summary of the overall architectural thinking.

In this one, I’m going to run through some of the key policies and developments around online identity during this same timeframe. So let’s start back in 1996 with the Government Direct green paper, which recognised that:

“…. something like a cash dispenser card is going to be needed for dealing with machines like public access terminals or, in the future, with terminals in the home … for some transactions government may need a higher level of certainty about the identity of an individual than the arrangements used for telephone banking. This could involve the use of “smart cards” … The principle of these cards is the same as the older magnetic stripe cards – a piece of information on the card is combined with another piece of information, like a PIN number, to ensure that the right person is using the service. … The Government intends to carry out evaluations of available systems and conduct trials to find out the type of electronic signature which works best, and which is most convenient for people to use.”

In 1998, the Parliamentary Office of Science and Technology described the two alternative views of identity that have largely defined the debate ever since:

“The first holds that it is the responsibility of government to provide an official ‘citizens card’ once it expects people to use it to access and validate official transactions – just as it provides other documents such as passports and driving licences. The alternative view is that if there is a ‘market’ for ‘identity’, then it can be met by any number of private means and does not need a single official mechanism which could be portrayed by some as the equivalent of a national identification card. If a unitary approach were taken, an obvious candidate to provide the template for a citizen’s card would be the ‘Benefit Card’ already being introduced and which will need to be held by a significant proportion of the population. In favour of this (if this were to be a smart card) would be the likely efficiency gains through allowing broader functions to be built upon it. Against it could be the possible stigma (whether because of its association with benefit claims or the fact that the original motivation for the card was fraud prevention).”

Several demonstrators and pilot programmes making use of smart cards were developed by the Central IT Unit (CITU) during the mid to late 1990s, including one that modelled potential electronic voting in a London-wide election and another that modelled notifying government once of a change of address. These used Royal Mail’s Viacode and Barclays Bank Endorse smart cards. The logical schematic of the change of address demonstrator, which used XML and other open standards such as HTTPS, LDAP and SMTP, is shown below.

change of address demonstrator

The e-Government Authentication Framework from 2000 had as its focus the problems of ensuring that:

    • a given identity actually exists
    • a person or official of an organisation is the true holder of that identity
    • identity holders are able to identify themselves for the purpose of carrying out a transaction via an electronic medium

It identified the need for government to only release personal or commercially sensitive information against reliably verified identity, to provide services and benefits only to those entitled to receive them and to protect people against misuse of their identities. Its key philosophy was that

“Government will encourage the provision of authentication services by a variety of bodies, including local authorities and the private sector, and will seek to make use of these services wherever possible … Where third-party service providers are conducting transactions on government’s behalf, they will be required to authenticate the citizens and businesses they deal with to the same standards as government itself would. Government will in turn accept transaction data from those service providers, who will certify that they have carried out the authentication transaction to the agreed standard.”

So out of the two potential models outlined in the earlier Government Direct paper, a federated identity model was to be the preferred choice, enabling the development of an identity ecosystem that could tap into existing organisations able to confirm online the identity of individuals. Four levels of trust in terms of the quality of identification required were established:

0 — Informal Transactions
1 — Personal Transactions
2 — Transactions with financial or statutory consequentials
3 — Transactions with substantial financial, statutory or safety consequentials

Each of these levels required a progressively more significant level of registration, authentication and verification services — from none required at Level 0, to full face-to-face initial registration at Level 3 together with the use of “a digital certificate. This will preferably be held in a secure token, such as a smart card. Users will demonstrate their right to that credential through the use of a private key and a password or biometric. The system will authenticate users based on the validity of public key / private key pairs, and on the validity of the credential.

In 2001, the UK Government Gateway was launched, providing a range of transaction management and identity-related services to turn policy into reality. As mentioned in Part 2, the Gateway provided the infrastructure required to connect government into the federated identification and authentication services being provided by third parties via smart cards — such as Barclays Endorse, Royal Mail’s ViaCode and certificates being issued by the British Chambers of Commerce. When the smart card market largely collapsed in the fallout from the dotcom boom and bust, the Gateway ended up primarily using UserIDs and passwords — limiting the level of services that could be used (since UserIDs and passwords were not capable of establishing the levels of trust and authentication possible with smart cards).

The Gateway’s core services were designed to meet various needs including:

    • authentication (we know who the person is)
    • authorisation (we know they are entitled to use the service)
    • the capacity they’re operating in (i.e. their role)
    • varied credential types (userID/password, digital certificate, etc.) issued potentially by various (trusted) parties

It also needed to meet the government’s requirement to support delegated rights:

    • to third parties (agents / intermediaries acting on behalf of people)
    • to assistants within an organisation (subsets of user rights, such as those needed for an employee working on VAT returns within a business)

In addition, it provided reliable, secure, two-way transactional synchronous and asynchronous messaging between citizens, businesses, intermediaries and government — including, where appropriate, the authentication of those messages.

The solution adopted the open standards proposed by the UK government as the way to underpin its e-Government programme and formed part of a wider move towards a Service Oriented Architecture (SOA) for government. Key elements of this included:

    • metadata framework: Dublin Core / W3C Resource Description Framework
    • security framework: ISO/IEC 17799:2000 information technology, code of practice for information security management, Common Criteria
    • data interoperability: IETF, W3C, WS-I (including WS-Security), OASIS interoperability standards (eg. XML, SOAP, SAML)
    • management and operations: OGC ITIL

Government Gateway

In 2001, the “E-government strategy framework policy and guidelines: Registration and authentication” addressed security requirements related to the provision of registration and authentication services to support access to e-government services. It defined these two key processes as follows:

    • Registration: This is the process by which a client gains a credential such as a username or digital certificate for subsequent authentication. This may require the client to present proof of real-world identity (such as birth certificate, passport) and/or proof of other attributes depending on the intended use of the credential (eg proof that an individual works for a particular organisation). Registration can be associated with a real-world identity or can be anonymous or pseudonymous.
    • Authentication: The process by which the electronic identity of a client is asserted to, and validated by, an information system for a specific occasion using a credential issued following a registration process. It may also involve establishing that the client is the true holder of that credential, by means of a password or biometric. A client is required to authenticate their electronic identity every time they wish to engage in an UKonline session.

The main purpose of the model was to establish the framework for the federated identity system, setting out the approach to the provision of all or part of e-government services by third parties, including obligations on third parties for registration and authentication. It also set out the various trust models for registration and authentication. It further clarified the requirements both for initial registration and subsequent authentication across a range of government services. An updated version, Version 3, appeared in 2002, and incorporated comments received after a public consultation exercise.

The federated identity model was part of a wider federated approach, one that foresaw a mixed economy in the supply of online government services, with many to be available through third parties (intermediaries) as well as direct from government itself. This was detailed in the 2003 “Policy Framework for a mixed economy in the supply of e-government services” consultation document which aimed to

“… create mixed economy — a marketplace where government, private and voluntary sectors can come together to deliver e-Government services that better meet the demands of our customers. A successful mixed economy will be a force for maintaining the UK’s position as a leading knowledge economy. For this to happen we will need a clear framework for government and intermediaries to participate. This document describes what needs to be done, the opportunities and the principles of intermediary involvement, and the support we are putting in place to drive our agenda … in three years, there will be a mixed economy in the supply of public services, where consumers (citizens & businesses) can engage intermediaries from the public, private or voluntary sectors to use public services in the manner that suits them.”

intermediaries

One such example given is:

“Simple Transaction – Motorist Organisation. A motorist services company might want to add Vehicle Excise Duty (car tax) to their portfolio. Their offer becomes more of a “one-stop-shop” and is likely to increase customer loyalty, or attract new customers to the service.”

(As an aside, this approach is quietly radical in its implications: in this simple example of Vehicle Excise Duty, VED, it has moved the debate from a narrow discussion of better ways of automating current processes within an existing organisational structure, such as DVLA, and is instead evaluating options that would potentially see other players undertake the functions previously done by government. After all, why not let insurance companies collect VED in the same way most other tax collection, such as VAT and PAYE, is already outsourced to retailers, employers etc.? This type of fundamental rethink of how best to achieve outcomes rather than to think within existing constraints has all too often been absent when considering how best to use technology to redesign and re-engineer public services)

Anyhow, back to our story … The Gateway’s identity services were later enhanced to support EMV (the chip and PIN standard developed by Europay, MasterCard and Visa and widely used for for authenticating credit and debit card transactions).

trust framework

trust architecture

In parallel with these developments, and in apparent conflict with the earlier approach to a federated identity model, the government decided to pursue the development of a single national identity card that would be issued by the state. After many years of encouraging the growth of an ecosystem of identity providers and intermediaries, this model would have instead imposed a single identity for use with government services. These proposals for a single identity card formed part of the National Identity Scheme in 2005. It’s outside the scope of these overview 101’s to go into the pros and cons of what was proposed, so for anyone interested in more detail have a look at Wikipedia’s summary. Under the terms of the Identity Documents Act 2010, identity cards ceased to be legal documents on 21 January 2011.

Since the general election in 2010, a familiar model has been proposed, one that returns to the earlier desire for a federated identity system. The Government Digital Service (GDS) is running the identity assurance programme (IDAP) and is both developing the technical standards needed to implement a replacement federated identity model for the Government Gateway (which is due to end providing services in 2016) and putting into place the ecosystem of third party identity providers required to make it happen.

“Identity providers are organisations paid by the government to verify people’s identity so they can sign in securely to government services. Identity providers will have to meet industry security standards and identity assurance standards published by the Cabinet Office and CESG (the UK’s national technical authority). There are currently 5 identity providers — Digidentity, Experian, Mydex, the Post Office and Verizon — eventually there will be more. You can choose to register with more than one of them, and you can stop using an identity provider at any time.”

GDS has also recently announced a further initiative to bring in more identity providers, to further expand the choice open to citizens and businesses in the future.

They have set out 5 reasons for using third party identity service providers rather than doing this from within government:

“1. user choice – you will be able to choose your identity provider(s) and stop using a provider if you want

2. no centralised identity database – instead, to protect users’ privacy, each identity provider will be responsible for securely and separately holding data about the users that have registered with them. Each government department service will only have access to the data it needs.

3. security – using several identity providers is more secure and less vulnerable; there is no single point of failure and no single service that holds all the data in one place

4. developing a market – we’re giving identity providers freedom to design services to meet the standards. This will allow them to develop services that can be used by the wider public and private sector, which will help to reduce costs.

5. making the most of available technology – the technology and methods for identity verification are constantly evolving; specialist private sector organisations are better placed than government to keep up with these developments”

The independent Privacy and Consumer Advisory Group has also been providing guidance and advice to GDS to help ensure they’re designing a service based on user choice, control and privacy — and that there is an easy to use route to fix problems if they arise.

The new identity service is already in live private beta with two exemplar government digital services — HMRC’s PAYE and DVLA’s view driving record service. These are being progressively tested, developed and improved prior to being moved into public beta. The intent is that over the next few years online identity provision will adopt the new federated identity service. Users of the Government Gateway identity services will be progressively migrated to the new service, ahead of the Gateway infrastructure being wound down and eventually decommissioned.

IDAP beta

So, if all goes to plan, over the next few years we should see a modern version of the original federated identity model foreseen back in the 1990s. The technology may have changed from that originally envisaged — of smart cards and PKI — to one of chip and PIN and other potential mechanisms, but the intended outcomes remain largely the same: to enable citizens and businesses to use online government services in a trusted and secure way.