Finally … An Identity Framework For The Public Sector To Build On

When it comes to collecting taxes, our governments are excellent at integrating the citizen. But, most other things … not so good. Why…
Photo by Vadim Bogulov on Unsplash

Finally … An Identity Framework For The Public Sector To Build On

When it comes to collecting taxes, our governments are often excellent at integrating the citizen. But, most other things … not so good. Why? Because there is almost no thought given to the integration of citizens. For example, my digital integration into the NHS barely exists. In fact, my dentist has much more digital integration than virtually all of the government and council services that I use. There is very little thought about how a citizen will interact with online services, and how our identity can be shared across the public sector.

Apart from collecting my taxes, I barely exist for most public services. And, the weakness is that they all build on sand, and will never integrate with the citizen until there is a common data architecture that can share what needs to be shared, and makes sure that other things are not shared. As part of this, the citizen must also have some control of their own identity. There are some great examples around, such as, in Scotland, for the Young Persons’ (Under 22s ) Free Bus travel, and which uses Yoti to prove identities.

But, there is hope, and in the UK it comes in the form of a policy paper of:

Within this, we actually start to see the foundation develop at a foundation layer, and where it lays out a basic taxonomy for a digital identity framework:

You might need to check if a person is a ‘representative’ of someone else (also known as a ‘subject’) before you give them access to your service. Being a representative gives them permission (or the ‘authority’) to do things on behalf of the subject.

Authorities

This type of approach starts to define delegation of authority, and which is a key element within the trusted infrastructure. The framework defines: delegated (someone has appointed someone to represent them), asserted (someone has the authority to represent them), and appointed (some third party has appointed the person).

But, how do you check the trustworthiness of the authority to do something on someone's behalf? Well, often we ask the subject to provide evidence of this, or we create an authoritative roles within the given service. The evidence they provide will either be physical evidence of digital evidence and should:

  • identify the subject.
  • identify the representative.
  • explain what permissions the representative has been given.
  • explain when the permissions were given.

For the subject, the framework defines that one or more of the following is required:

  • a unique identifier.
  • their identity.
  • an authenticator.

The authority themselves may limit their role in some way, such as defining that they can only authorize for a given time period. In terms of the trustworthiness of this authority, the framework defines levels of trustworthiness:

  • Low trust: An email, PDF or letter. This has no security features.
  • Medium trust: This contains unique evidence, such as related to a unique reference number, and must include a reference to the subject’s identity, and the authority’s official name. For physical documents, there must be some protection on these, and which cannot be tampered with (such as printed on watermarked paper). For digital evidence, there should be cryptographic protection. Otherwise the authority may be on a list of approved or authorized people.
  • High trust: this includes a unique identifier for the subject and their representative, with the official names for these, and which have integrated physical security to protect against any changes to the evidence. For cryptographic evidence, there is digitally signed proof from a trusted authority.
  • Very high trust: This is defined as biometric information for the subject and representative, and/or with trusted digital signatures for the subject and representative.

There are a whole lot of other definitions and examples for this checking. A data schema is also defined for identity documents, ID claims, and assurance processes:

ID Claims:

  • Given name
  • Middle name
  • Family name
  • Address
  • Date of birth
  • Nationality Image

Assurance processes:

  • Trust Framework
  • Scheme Assurance policy
  • Confidence Level
  • Identity evidence profile
  • Strength
  • Validity
  • Activity history ID Fraud
  • Verification
  • Organisation

Proofing processes

  • Validation Methods.
  • Verification Methods.
  • Activity ID Fraud checks.

ID Evidence (Aligned to GPG45):

  • Passport
  • EU or EEA ID cards
  • Passport card
  • UK driving licences EU or EEA driving licenses
  • Military identity card
  • Proof of age card
  • Home Office travel document
  • Older person’s bus pass Education certificate
  • Rental agreement
  • Purchase agreement
  • Proof of age card
  • and many other documents.

Conclusions

It is hardly an actual infrastructure that could be used in practice, but it’s a good starting point. Hopefully, in the future, we will see a more complete infrastructure for public services and the integration of the citizen.