This blog post is for anyone interested in the technical development of GOV.UK Verify.
There are 3 parts to GOV.UK Verify: the hub (which allows communication between the user, the certified company, and the service on GOV.UK); the certified companies’ service (which verifies your identity and confirms it to government); and the Document Checking Service (which allows the certified company to check digitally that your given information matches a valid record).
The GOV.UK Verify delivery team is responsible for building and maintaining the GOV.UK Verify hub and Document Checking Service. We are organised into 3 teams around our current technical delivery priorities. These are: increasing adoption of GOV.UK Verify, improving and maintaining GOV.UK Verify and reducing our technical debt.
These teams are made up of developers, engineers, analysts, product managers, delivery managers and architects.
In this post I’ll explain what we’ve been working on over the past 2 weeks and what we plan to do next.
Increasing adoption of GOV.UK Verify
We want departments across government to adopt GOV.UK Verify increasingly as it progresses from beta to live because it’s secure, straightforward and meets the needs of their users. Here are the things we’ve done to improve GOV.UK Verify and make it better for end users:
- completed an AB test that proved we should stop asking users if they access to their financial records when recommending the best certified company for them
- developed a tool for the DVLA to enable them to performance test their matching service and our matching service adaptor
- made it clearer to users that they need to have their documents with them during verification
- began recommending relevant certified companies to users who have a photocard driving licence from Great Britain and a smartphone
- improved our analytics of the answers users provide on the hub
- allowed users to return to the hub from a certified company and choose another one within the same session
- improved our performance monitoring and reporting to make it more accurate
Improving and maintaining GOV.UK Verify
We want to improve the way we run the GOV.UK Verify federation and ensure we’re ready to run a live service come April 2016. To keep GOV.UK Verify available and secure, and to meet the most pressing needs of end users, we’ve:
- released a new version of the Matching Service Adapter with performance improvements. The Matching Service Adaptor is a tool which simplifies the integration with GOV.UK Verify.
- resolved an issue with the Compliance Tool which prevented a department from being able to test their service during the onboarding stage
Reducing our technical debt
To reduce accumulated technical debt and allow us to continue to deliver at pace, we’ve:
- improved the logic behind questions on the hub and the certified company recommendations, allowing us to make improvements faster in the future
Things we plan to do next
Over the next 2 to 3 weeks we expect to:
- run an A/B test to assess a potential improvement in the hub user journey
- continue to improve our performance monitoring and reporting
- continue to adapt the hub to accommodate new certified companies and verification options for users
Subscribe to the blog and keep up to date with GOV.UK Verify's latest technical developments.
2 comments
Comment by Philip Virgo posted on
What is "technical debt?"
I should perhaps add that I am still trying to understand the business case for the Verify programme - given that DWP and HMRC now appear to be going down different paths because so few of their needs have been met and so many of the problems encountered with the DEFRA experience have still not been resolved,
Comment by Janet Hughes posted on
Hi Philip, thanks for the comment.
When we talk about technical debt, we're talking about things we need to do to the GOV.UK Verify codebase to tidy up accumulated impact of having made a lot of different changes over time. Sometimes we make decisions to leave certain things working well enough but not completely 'finished' so we can move faster at the time, knowing we will need to come back and finish it off later because otherwise it will slow us down in the long run. We've decided we now need to do some work to repay some of our technical debt, to make it easier and quicker for the team to manage and make changes to GOV.UK Verify's codebase. In turn, that will make it possible for us to keep iterating and improving the service for users.
HMRC and DWP aren't going down different paths - they have alternatives in place because GOV.UK Verify is still in beta, which means we are constantly scaling, developing and improving it based on feedback and evidence. We've published our objectives for taking GOV.UK Verify from beta to live by April 2016 on our blog, and we regularly post updates about our progress. By the time we go from beta to live in April 2016, departments will be able to start phasing out alternatives because by then GOV.UK Verify will work for 90% of UK adults, with further improvements planned after that to increase coverage beyond 90%. We've said that whilst we're still developing GOV.UK Verify in beta in this way, we expect services to keep alternatives in place as well so that where Verify is in use during our public beta users are able to choose other ways to access services if GOV.UK Verify doesn't yet work for them.
You can follow our progress in our regular updates, and you can follow department's plans in our regular posts about which services are planning to use GOV.UK Verify (the most recent one is here, including services in a range of departments including the ones you've mentioned: https://identityassurance.blog.gov.uk/2015/11/02/government-services-using-gov-uk-verify-november-2015-update/)
The business case for Verify is based on GOV.UK Verify providing value, a consistent experience for users and a consistent approach to security security as a cross-government solution rather than the wasted effort and cost that would be involved in each department building and maintaining its own solution. Verify also brings wider benefits because of its standards-based, federated approach. These include stimulating competition and innovation so the service is constantly developing and improving for users; building a market that can provide identity assurance across the whole public sector and for private sector services; being more resilient because it draws on a much wider range of data sources, methods and systems.
Thanks again for your question - I hope this gives you the answers you need but please come back if you have any more questions or would like any other information or clarification.