GOV.UK Mobile Wallet alpha assessment
Service Standard assessment report GOV.UK Mobile Wallet alpha assessment 30/04/2024
Service Standard assessment report
GOV.UK Wallet
| Assessment date: | 30/04/2024 |
| Stage: | Alpha |
| Type: | Assessment |
| Result: | Amber |
Previous assessment reports
- N/A
Service description
The GOV.UK Wallet will provide users with a convenient and secure way to access, store and use their government issued credentials, so they can more easily interact with services in the public and private sectors.
This assessment focused on the basic DBS check credential which will enable users to add their results in the GOV.UK Wallet and share using DBS’s existing share code service.
This service aims to give a credential holder a convenient way to store, access and use their government issued credentials, so that they can provide the necessary documents to prove something about themselves or access a service.
Service users
This service is for:
- credential issuers: Any HMG Department who wishes to issue digital credentials to their users
- credential holders: Any user of the GOV.UK mobile app with an active GOV.UK One Login who needs to store and manage their government issued credentials
- credential consumers: Any person or organisation who needs to verify an individual’s government issued credentials
Things the service team has done well:
On Standard 1, understand users and their needs
- the team demonstrated a good understanding of their users, their needs and the complex process of managing and using credentials.
- the team made good use existing research and worked closely the DBS teams to gather insights.
- while the team has used a variety of methods the work would benefit from the use more methods that allow for observation of user behaviour, especially in context.
- while working with service teams the team is learning what they need to make use of the wallet platform.
On Standard 2, solve a whole problem for users:
- the panel is cognizant that the assessment is linked to the private beta specified, and the standard rating recognises that. There is work to do for the end of private beta to be better able to fully articulate the problem space, and to ensure that each department that onboards to the Wallet service can clearly set out why this is making things better, on a use case by use case basis.
- for the private beta, the scope of their work is well defined and they are thinking ahead to the challenges of the wallet app being part of the GOV.UK app.
- the team considered alternatives to the wallet app approach.
- the team is working with a range of other teams to develop the app - for example, content design collaboration with DBS.
- the team has considered the Credential Holder to be their MVP, and the panel acknowledges that a lot of work has been done on their experience. However the panel would recommend that the experience of the Credential Consumer is reviewed thoroughly for the MVP and any future development, as there are also benefits from improvements in this journey. Consideration also needs to be given on behaviour change to these Consumers, so that only the information needed is stored in the wallet - rather than including everything and increasing the risk because that’s what Consumers are used to seeing.
On Standard 3, provide a joined up experience across all channels:
- the team recognised the risks posed by users falling out of the journey between touchpoints (web, app) and is designing to mitigate that risk based on UR around hand off scenarios.
- UR has been conducted with some participants starting on mobile, some on desktop, and this has been considered in every round.
- the physical DBS certificate will still be issued, and the user will retain this option on an ongoing basis.
On Standard 4, make the service simple to use:
- the team is being careful to ensure consistency of design patterns across platforms (GOV.UK, Wallet).
- the team is adopting native navigation patterns already in use in popular wallet apps.
- the team is applying recognised GOV.UK, Apple and Android design patterns and content style guidance, and is building a library of the patterns and components it’s using.
- even though it seems obvious to call it Wallet, the team has not done this without thought and is still open to alternatives.
- the team is making sensible and appropriate use of images and illustrations to guide users through the journey.
On Standard 5, make sure everyone can use the service:
- there’s a range of assisted digital and help routes.
- the team is conducting accessibility testing on the end-to-end journey, and plans to deep dive into this further prior to private beta.
- there will be a Welsh version of the service.
On Standard 6, have a multi-disciplinary team:
- the team had a strong sense of togetherness, which came through to the panel during the assessment. The team culture seemed strong, and there is a good level of thought being given on how to on/offboard colleagues, and how to keep open dialogue going through the team/pod/programme.
- the panel is encouraged that the team will remain in place into the private beta phase.
On Standard 7, use agile ways of working:
- the team was able to demonstrate throughout the assessment their ways of working, and strong relationships within and external to the team.
- the panel is encouraged that there is external oversight for the team, particularly with other governments, and with security sector colleagues.
On Standard 8, iterate and improve frequently:
- there’s good evidence of iterating designs based on user research results, for example, the ‘1 of 2’ label rather than stacked cards and the ‘add a document’ journey.
On Standard 9, creating a secure service:
- the team had a strong sense of secure architecture and engineering by design.
- the team maintained good engineering practice with DevSecOps to ensure security of the services including development, deployment and data access and storage.
- the team used appropriate security mechanisms (including TLS, KMS) to secure the data in transit and at rest.
- the team used multiple non-production environments for testing and integration.
- the team made use of the secure enclave on devices to store the security keys and data.
- the team had a security lead.
- the team had DP and IA personnel working with ICO and legal representatives within the team to ensure the app was in compliance with Data Protection Act 2018 to protect citizen’s data.
- the wider programme, OneLogin has a Fraud team, to investigate the potential criminal risk and journey.
- the team is aware and plan to use selective disclosure wherever appropriate, as per ISO Standard 18013-5, and are considering where pseudonyms can be deployed for future use cases.
- the team is working with and building upon the work of the wider One Login and Digital Identity Programmes.
- the team is storing personal details off cloud. The panel is pleased to note the additional measures the team plans to include in conjunction with One Login, including remote log out and document revocation.
- the team was able to supply and talk through the decisions that they have made to keep sensitive, personal data secure, and the panel is encouraged by the privacy by design principle that is used. The team was able to share precedents for the decisions that they’ve taken.
- the team is working with the One Login Fraud Pod to ensure that they are building upon what has already been approved through the assessment process.
On Standard 10, define what success looks like:
- the team had a good, broad sense of what they want to measure and what success looks like. As per the discussion on the day, the team need to consider a) whether the metrics they are suggesting are truly impacted by the wallet, rather than being under the auspices of the owning department b) a standard set of metrics around take up and engagement that can be presented at the start of any work with future teams and c) service specific metrics that consider the Consumer Consumer as well as the Holder.
On Standard 11, choose the right tools and technology
- the “Wallet” was designed to be a component within the GOV.UK App and the team is reusing the OneLogin mobile app platform and tools for the development of this “sub-app”.
- the team evaluated the choice of backend databases, and made a conscious decision, evidenced with a decision record to go for different database technologies for Android and iOS.
- the team made use of modern deployment and analytic tools, including Github Action, Google analytics, app stores analytics.
Recommendation in beta: The team should investigate the possibility of reusing the EUDI wallet toolbox, which include common standards and technical specifications in EUDI reference implementation rather than starting from scratch for quicker time-to-market.
On Standard 12, make source code open
- the team mentioned it was inappropriate to open source the code at this stage, because Wallet has not been publicly announced as a government policy.
- the team mentioned they were following the coding in the open guideline with regards to unreleased policy, and plan to open source the code committed to an MIT licence.
- the team shared the links to the open source code bases.
In beta assessment, please show evidence of coding-in-the-open. We would like to see a plan to explain which code bases would be open and which ones are kept closed, as well as evidence of practice of coding in the open.
On Standard 13, use and contribute to open patterns
- the team had understanding of open standards related to the service including OpenID Connect & W3C apis.
- the team reused OneLogin mobile app platform, and showed intention to integrate with OneLogin and other Government services including GOV.UK Notify.
- the team had interoperability in mind, and understood the trade-offs of hardcoding the data map in the app and the effort to reverse the decision if necessary in the future.
- the team has and continue to engage with the Gov.uk design system team, adopting patterns where possible.
On Standard 14, operate a reliable service
- the team used test-driven development.
- the team used Github actions to enable CI/CD.
- the team used multiple environments for development, function and integration testing.
- the team planned to apply tools for monitoring the resilience and performance of the apps including Google analytics, crash reports, app store statistics.
In beta assessment, we would like to see evidence of tools for monitoring fraud and app security.
1. Understand users and their needs
Decision
The service was rated amber for point 1 of the Standard.
During the assessment, we didn’t see evidence of:
- a good level of research with the Credential Consumer, who is a key part of the planned alpha (and where the benefits of this service can be realised) . The acceptance of digital credentials is key to the success of the wallet. Potential credential consumers are a large and complex user group which makes research challenging. The team plans to do research with this group. It’s recommended that this is done before moving into private beta, with a diverse geographic sample and in context. Doing this would give the team the opportunity to identify potential behaviour and contextual barriers to the adoption of digital, wallet-based credentials. It will also help refine the team’s understanding of what information needs to be presented to the credential consumer for them to find it acceptable. The insights from observing credential consumers may also help the team design their approach to research in private beta
2. Solve a whole problem for users
Decision
The service was rated green for point 2 of the Standard.
3. Provide a joined-up experience across all channels
Decision
The service was rated green for point 3 of the Standard.
4. Make the service simple to use
Decision
The service was rated green for point 4 of the Standard.
5. Make sure everyone can use the service
Decision
The service was rated green for point 5 of the Standard.
6. Have a multidisciplinary team
Decision
The service was rated green for point 6 of the Standard.
7. Use agile ways of working
Decision
The service was rated green for point 7 of the Standard.
8. Iterate and improve frequently
Decision
The service was rated green for point 8 of the Standard.
9. Create a secure service which protects users’ privacy
Decision
The service was rated amber for point 9 of the Standard.
During the assessment, we didn’t see evidence of:
- challenge back to DBS in terms of what information should be stored in the wallet. Whilst the panel notes this is as per the requirements provided, they recommend that work is done with DBS to ensure there are no missed opportunities
- work to detail the revocation process. The panel notes that the current process is simply to issue another credential – work should be done with DBS (as the risk owner) as to whether there are opportunities to make a digital service safer and more secure
Recommendation in Beta:
- scoping the future pen tests to include the OneLogin and all the integrations.
- at Beta assessment, demonstrate strong access audit and controls around development and deployment, principal of privilege access and regular credential rotation.
- continue to challenge each partner agency on the information required for the wallet, to ensure that it is not placing the user at greater risk of loss of data and identity fraud. Pseudonyms should be considered as appropriate.
- continue to work with CDDO on the requirements for ongoing assessments outside of the DBS/NINO work and recommend that a commitment of this assessment is that regular challenge should be sought from the CO Technical Design Authority.
10. Define what success looks like and publish performance data
Decision
The service was rated green for point 10 of the Standard.
11. Choose the right tools and technology
Decision
The service was rated green for point 11 of the Standard.
12. Make new source code open
Decision
The service was rated green for point 12 of the Standard.
13. Use and contribute to open standards, common components and patterns
Decision
The service was rated green for point 13 of the Standard.
14. Operate a reliable service
Decision
The service was rated green for point 14 of the Standard.
Next Steps
This service can now move into a private beta phase, subject to addressing the amber points within three months time and CDDO spend approval.
To get the service ready to launch on GOV.UK the team needs to:
- get a GOV.UK service domain name
- work with the GOV.UK content team on any changes required to GOV.UK content