Working with Verify

Date posted
27 July 2015
Reading time
7 Minutes
Chris Cartin

Working with Verify

As a consultant working on a UK Government Exemplar project, one of the most interesting areas of work was the integration with .GOV Verify (then IDA). At that time there were very few other government services making use of Verify and the on-boarding process was less defined, so delivering the integration was a great opportunity to gain a practical understanding of the identity platform. Our team learnt a lot, both on the technical implementation and also the challenges faced when delivering a solution that ensures the best user journey possible.
As the methodology was SCRUM, the team created a number of user stories that covered the scope of the integration. The related Epic user story had a clearly defined user need (the ability to authenticate via Verify) but the sub-stories were more technical in nature relating to the various scenarios a user might encounter as they accessed the service.
They key challenges were:
  1. Integration test hub
.GOV Verify logo Firstly, while following the GDS on-boarding process, several test hubs are available to allow the components to be tested. This works well for testing individual integration points but doesn't allow for end to end testing of the entire process. To test more thoroughly access is required to a fully featured Verify Test hub but access is not granted until the service has passed through some assessment.
To enable the team to thoroughly test components, a local version of the Verify integration test hub was set up. This also proved useful at show and tell sessions, as it enabled the team to explain how the flow worked and demonstrate the work carried out during a Verify integration sprint.
  1. Matching
It is generally accepted that one of the difficulties with Verify integration is matching the real-world Verify identity to the record the organisation holds for the individual. Typically the existing record comes from a legacy system or perhaps from a combination of existing systems. As the quality of this data can vary considerably, the challenge can be in locating which existing records matches the Verify identity.
Inevitably a trade-off is made when improving the probability of a match, while maintaining a fairly strict set of criteria, to reduce the chance of several legacy records matching the provided identify.
On this project we worked with the data team and Subject Matter Experts to produce an initial set of matching rules. After the initial deployment, monitoring was used to understand how many matches were failing and the reasons why. Armed with these insights the matching criteria was then iterated on to constantly improve the matching success rates. Through this process we discovered that although our initial concern was over the quality of legacy address data, it was actually the information coming from the various Identify Providers that was less accurate or not in the exact format we expected.
  1. Tiger_MissionPatchVerify assistance
Although the Verify success rate is continuously improving, there can still be instances that some users will not be able to easily authenticate with Verify. To support these users, our team worked with the client to provide a parallel authentication mechanism. This solution offered a one-time password function to ensure the service remained accessible to all users.
Conclusion When we started this piece of work I thought the technical build would be the tricky part but in reality the challenge was adapting what was already built in a constructive way, based on user feedback and research.
From my experience on this project, successful Verify integration depends on putting user needs first and understanding how they are likely to interact with the service.

About the author

Chris Cartin