Working with Verify
Date posted
27 July 2015
Reading time
7 Minutes
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:
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.
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.
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.
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:
- Integration test hub
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.
- Matching
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.
- Verify assistance
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.