A key project hypothesis is that local authorities collect high quality information, governed by rigorous processes, that will be suitable for helping their customers achieve a GOV.UK Verify identity. This will be invaluable for those customers who do not have the digital footprint necessary to successfully complete the existing GOV.UK Verify online registration process. Those customers will typically be in the lower socio-economic groups, and will typically be the heaviest users of local authority (and central government) services. Enabling those customers to engage digitally, with a secure and highly assured online identity, will therefore be particularly beneficial.
The findings reported here are based on detailed work with our local authority partners.
Documented processesWe started by reviewing the documented processes used by our partner local authorities to register new applicants on the social housing register. As we had expected, the processes documented are very thorough, reflecting the level of risk and potential fraud relating to social housing, but also reflecting the level of scrutiny that local councils are under.
Applicants have to produce a good range of original identity and eligibility documents that are checked and recorded by trained staff. These include two proofs of identity, two proofs of address (and evidence for how long the applicant has lived in-borough), proof of dependents, proof of income, proof of savings and capital, evidence of tenancy and evidence of national insurance number.
The documented processes were very strong, but the acid test is whether or not practice on the ground matches up to theory. To check that we carried out detailed information governance observations.
Information Governance observationsDetailed information governance observations were carried out at the local authority offices. Our information governance expert, Ian Imeson, spent a day with each council, observing how the front and back office teams collect, check and verify the identity and eligibility evidence provided by the social housing applicants.
It was clear that the staff involved in these processes are well trained, with new staff being mentored and supported until they have mastered the identity checking processes. Only original documents were accepted as identity evidence; photocopies and documents printed from the internet are rejected. Documents containing anti-counterfeiting features are scanned for authenticity in some local authorities. Applicants who post their identity and eligibility documents are expected to attend a face to face interview later to confirm they are the true owner of those documents.
Anti-fraud checks are extensive, including cross checks from DWP award notices and pay slips to bank account receipts. Any suspicion of fraud is followed up with a credit reference agency check.
Checks to see if an applicant is eligible to be on the social housing register are also valuable as proof of identity.
Although the identity and eligibility checking processes were not designed to meet the requirements of Good Practice Guide 45 (this GPG, published by GDS, sets out how identity should be proven and verified), there is a high degree of compliance across all of the categories of evidence – particularly the ID evidence presented and how it is verified. Extensive as they are, the counter fraud checks undertaken are not exactly as specified in GPG 45, but they are equally rigorous, and certainly adequate once combined with the anti-fraud measures already used by the GOV.UK Verify identity providers (IdPs).
The processes observed were considered sufficient to meet the requirements of an IdP to create an identity at level of assurance 2 (LoA2)*, when combined with the IdP’s normal anti-fraud checks. In some cases level of assurance 3 (LoA3) could be achieved.
Presenting the data to the IdPs – the metadata schemaWe will look in more detail at the technical architecture in the next blog. But the glue between the data collected by the local authorities and the technical architecture for transmitting it to the IdPs is the metadata schema we are developing to describe the data. The metadata schema is designed to help the IdPs understand the value of the local data for identity verification, but it is the IdP’s responsibility to make the final decision on the level of assurance achieved.
The metadata schema is likely to develop as we move through the technical integration stream, but the first draft contains the following attributes:
| Data item | The data being presented |
| Data category (ID, Activity History, Knowledge Based Verification) | Describes the type of data represented and which Identity Verification category it sits within. |
| Date data recorded | The date when the data item was first recorded |
| Currency (last updated) | The date when the data item was last updated |
| Self-asserted or verified? | Has the data been verified by a council officer |
| Method of verification | E.g scanning technology used, manual check. We need to develop a pick list for this item. |
| Mandatory or Optional | Will this data item always be present, or only sometimes? |
| Activity History definition | Is the activity history in question of high, medium or low value. This will be based on an agreed categorisation. For example, a history of automated payments would be of low value. |
| User’s level of assurance when data was recorded (LoAx) | This will indicate if the data (particularly if self-asserted) was bound to a more or less highly assured identity |
| Cross-checked against… | Has this data item been crossed checked in any way. E.g. has the amount on an award notice from the DWP been crossed checked against payments in to the individual’s bank account? |
The attribute exchange team in GDS is currently working on attribute metadata, and we will incorporate lessons from their work as and when available.
Self-certification of local sources of dataThe project is looking at the sort of process that might be put in place to allow potential local sources of identity data to self-certify that they meet the necessary data and process standards for GOV.UK Verify. Self-certification is necessary to make access to local data both scalable and affordable. The self-certification processes would need to be developed more fully in a Beta project, and ultimately it is down to the IdPs to agree and sign off the self-certification standard, and individual assessments against it.
The following table describes the sort of criteria that might be used in a self-certification process.
| Written procedures | Does the organisation have formal written procedures for ID verification? How are these signed off? What is the review process? |
| Staff training | What training do staff receive in identity verification, in document checking, and in anti-fraud procedures? Is regular refresher training delivered? |
| Documents accepted as proof of identity and eligibility | The range of documents that must be presented, and their strength as defined in GPG 45 |
| Policy on original documents | Which documents must be presented in their original format; when are copies/prints from the internet accepted? |
| Use of scanning devices | Are scanning devices used to detect fraudulent documents? If so, in what circumstances? |
| Counter fraud measures | What counter fraud measures are deployed e.g. credit record agency checks, other cross checks? |
| Quality assurance processes | For example, do supervisors carry out cross-checks and spot checks to ensure processes are being followed correctly? |
| Face to face checks | Are face to face checks carried out to link individuals to asserted documents (passports, driving licences etc)? |
| Cross checking | What cross-checks are made between different document types e.g. benefit payments into the bank account match the benefit awards notice? |
| Relevant accreditations | For example, the level achieved against the Information Governance Toolkit/Data Security and Protection Toolkit |
Related industry sectors already have experience in self-certification (e.g. the OpenID Certification Program and the OIXnet Registry) from which we can learn lessons in terms of legal, technical, and registration approaches.
ConclusionsThe more detailed work carried out in this Alpha project confirms the findings from our earlier Discovery project, that local authorities are a rich potential source of identity verification data that could significantly improve the IdP’s chances of successfully registering the “hard to verify” for a GOV.UK Verify account.
In the next blog we will look at the technical solution to making local data available to the IdPs.
By Ian Litton, project manager.
* LoA2 identities would stand up in a civil court; LoA3 identities would stand up in a criminal court. The checks that IdPs need to perform in relation to LoA2 and LoA3 identities are summarised here.*
