We are working with government teams to design a sign in and digital identity solution that supports our vision of a simple, joined-up and personalised experience of government for everyone. Last month’s post on the GDS blog outlined the problem we are trying to solve. One part of the solution to this problem is single sign-on, and today we want to share some key insights from our alpha phase.
Before we share our lessons learnt, we want to talk about how a single sign-on fits into the strategy for the digital identity. We started by talking to service teams about what they need. And then we broke the problem down into 2 statements.
We need to:
- create one simple, secure way for people to sign in to all government services (single sign-on)
- let users prove who they are to government once (digital identity)
This is a big challenge and there’s a lot to look at. So, another team in GDS is looking at digital identity, while we tackle single sign-on.
Why we’re working on single sign-on
Our overall vision is that:
- people will use the same username and password for every government service they use
- users can create a digital identity, to the level they need, which they reuse across government services
- every citizen who wants to access government services digitally will be able to use our service
Single sign-on is a known problem; service teams told us that they need a solution now. It’s also the front door to our wider digital identity service, and so it’s the first user need we have started to address.
What do we want the single sign-on service to offer? It should:
- allow a user to sign in and access government services
- give service teams confidence that it’s always the same user accessing the service (authentication)
And, as we onboard services, it will slowly become the only username and password users will need to remember to use government services.
What we’ve learnt
Recently we attended our alpha assessment with a panel of our cross government colleagues. I’m pleased to say that we successfully met the service standard. Our mission statement ‘A simple and safe way to log in for everyone, and an easy integration path for service teams across government’ resonated strongly with them.
During alpha, we recruited 329 end-user research participants for both quantitative and qualitative research. And we spoke to nearly 30 service teams from across 13 departments to understand what they need from an authentication product and an onboarding experience.
We wanted to share some key lessons from our alpha with you.
Lesson 1
Users don’t know which sign on works for which services
From our user research, we've seen how users struggle to sign in to the services they need to use. They:
- can’t remember which username and password works for which service
- think government is already joined up and so assume their existing username and passwords should work for all services
- get frustrated when government doesn't work the way they think it should
We want to reduce this confusion and help make government work the way users already think it does.
Lesson 2
Build on what we already know
A lot of good sign-on products already exist in government. They were never designed to work for all of government, but there’s still a lot we can learn from them and the experiences of their service teams and users.
We worked with the teams behind these services to understand what works well and the lessons we can learn around technology, usability and governance.
We worked with Veterans UK to connect the Apply for the Armed Forces Compensation and War Pensions Schemes in to test our technology and our process. Tom Stewart, Assistant Head of Modernisation for Veterans UK said, “We were able to integrate in just a few hours and, speaking as a Service Owner, my team and I are delighted to have been part of this crucial and exciting work.”.
We want to make sure we use open standards wherever we can, so we’re an OpenID Connect (OIDC) provider. OIDC is an open standard for authentication that is used in systems such as Open Banking and login.gov (US Gov equivalent).
We want to build on what government already knows and create one secure sign-in service that is flexible enough to meet the needs of different digital services and their users.
Lesson 3
It needs to work for service teams
Our product needs to be easy for service teams to join and use. We want to make the onboarding experience as straightforward as possible. Within 4 months we’ve talked to nearly 30 service teams to find out what they need from this process.
We did an experiment in alpha with the Armed Forces Compensation Scheme service. We wanted to see how quickly they could integrate with us. It took them 3 hours. We learnt a lot about how we can further improve our technical documentation for service teams.
We want to make sure what we build is right for service teams and is easy for them to use at every stage.
What next
We’re looking for central government services to work with in our private beta. Any service teams that are interested can find out more on our product page.
Use the product page to:
- register your interest in joining us in private beta
- find out more
- get in touch to ask us a question
- follow our progress
You’ll see on the product page that we’re calling our service GOV.UK Sign in for now. However, as we learn more, and our service develops, the name may change.
At the moment, GOV.UK Sign in is only for central government teams but we want to offer it more widely in the future. So, we’re keen to hear from services across government and the public sector to find out more about your needs and make the product as interoperable as needed.
Get in touch
If you’d like to join us in private beta, or have any questions for us, please get in touch on our product page.
Related blog posts:
A single sign-on and digital identity solution for government
GOV.UK Accounts: Enabling proactive, personalised and joined-up services