Here’s my paper providing an overview of Federated Identity for Access to UK Public Services: 1997-2020 (PDF):

Federated Identity for Access to UK Public Services: 1997-2020 (PDF)

As its catchy title suggests, it provides an historic overview of the UK Government’s approach to federated identity over the past 23 years, segmenting the journey into three stages:

  • the 1990s, and early government work with third parties from 1997 and the publication of its first authentication framework in 1999
  • 2000 onwards, and the continuing development of the authentication frameworks for individuals and organisations; the creation of tScheme and the use of accredited third parties; and the launch and development of the government’s first federated identification and authentication platform (the Government Gateway)
  • 2010 onwards, and the continued iteration of the government’s authentication frameworks; the renewed interest in the use of tScheme accredited third parties; and the launch of the government’s second federated identification and authentication platform (GOV.UK Verify), along with other related work including that of HMRC and DWP. It also briefly considers three issues—the role of third parties, “identity”, and privacy—that have proved consistent, and important, thematic elements throughout this journey, and concludes with a summary of the current status.

It isn’t intended to be history for its own sake—it aims to improve situational awareness and hence narrow the gaps between long-standing policy aspiration and technical implementation. I think there’s an opportunity to make significant progress in the coming year or so, but only if we learn and apply the many lessons of what has often proved a somewhat circular and repetitive odyssey. Consider this for example—it’s from the Cabinet Office in 1996, a year before the UK Government started experimenting with trusted third parties:

Some transactions with government (e.g. to claim a benefit) require proof of financial circumstances. This might be provided by one or more financial institutions such as a bank or a building society. Clearly, such institutions cannot send information about their customers to government on a regular basis. However, an arrangement might be put in place whereby a customer could authorise government … to request specific data from financial institutions. Arrangements would have to be put in place between government and financial institutions, to enable such authenticated requests to be forwarded and responses supplied to government.

That was written twenty-four years ago. Twenty-four years. And yet it sounds remarkably similar to what could now be achieved with an appropriate agreement between say users, Open Banking and public sector service providers. After all, the value of verified attributes was recognised long ago as being at least as important as “identity”—the government’s original 1999 authentication framework has numerous references to attributes, including the need to ensure:

… that the attributes associated with the identity are consistent, accurate and recorded in standard form.

Possible measures to ensure that attributes submitted … are accurate include … requiring that a trustworthy person or organisation confirm the information given.

Maybe its time to reset and radically simplify the technical approach—whilst ensuring trust through effective privacy and security—to reflect this pragmatic policy of 2000:

– work with a range of trusted service providers, to ensure interoperability with government processes

– identify where the marketplace is adopting suitable technologies for secure transactions and access, and ensure that the Government makes full use of these to meet electronic service delivery targets

All a bit “back to the future” perhaps, but worth reconsidering the second point above in particular given the rich variety of identity-related initiatives available that government could now tap into. Anyhow, read the paper and see what you think.

Errata, notes and queries

Since publication of my paper, I’ve had comments and feedback, documented below. In any future updates to the paper—most likely to happen once the post GOV.UK Verify landscape becomes clearer— I will address these issues where appropriate. I am very grateful to those who have found time to read and comment upon the paper.

General: “It’s confusing having numeric superscript for both footnotes and references”. In any update, I will use alphabetical superscript for footnotes to distinguish them more clearly from numerical references.

p.10. “Identrus should be IdenTrust”. While true, the quote (and incorrect spelling) is verbatim from the original source and therefore left it as it was originally published. The same is true of other varied and inconsistent spellings, such as that of tScheme, throughout the paper: it reproduces original sources exactly as they were written.

p.15. Regarding the Change of Address service: “This later spawned the Tell Us Once service from DWP that started in 2011 and is still in use today for notification of death to be propagated across departments.”

p.20. “… paid directly by the user to the tScheme third party …” should be “paid directly by the user to the tScheme-accredited third party”. Any future update will include this clarification.

p.23. Regarding the registration and authentication framework: “Notable also for introducing the concept that level of registration (verification) and level of authentication were not necessarily the same. It gives the example of the online provision of an anonymous medical test that must have the result delivered to the correct person.”

p.29. The text towards the bottom of the page “It also highlighted the requirements for identification and authentication…” refers to the European study describing the UK’s approach, and not specifically the Government Gateway. This is not sufficiently clear from the context, which could be taken to read as continuing to refer to the Government Gateway rather than the overall UK approach as described in the study. Any future updates will make this distinction clear, including that the later words in fact relate to another UK system operated by the DTI, referenced to illustrate how the UK’s approach was being adopted across multiple initiatives.

p.31. The Employee Authentication Service (EAS) is also notable in that “This was the first initiative that realised that authorisation was essential for access to systems like Every Child Matters and Contact Point. It thus laid the foundation for the use of trusted attributes linked to online identities. To this end, tScheme even developed a new Approval Profile for Attribute Registration.”

p.46. An additional clarification has been suggested, namely that: “eIDAS does not provide standards for eIDs, only Trust Services. For identity services it just requires that all notified national schemes should inter-operate but based on national standards.”

Last update: 06.09.2020