The Pensions Dashboards Programme has examined a wide range of options around providing an identity service. As part of that assessment, it has considered existing identity solutions, government services and those that are proposed for delivery in the future.
PDP is often urged to look to existing services and avoid ‘reinventing the wheel’. The practical approach is to secure a service through commercial partners with a background and experience in supplying identity services to support the ecosystem’s needs. So the programme will engage specialists to deliver this key part of the security / trust model.
PDP also decided to separate the provision of the identity service from the central architecture procurement. This approach has the following benefits:
- it provides greater flexibility to manage the services
- it keeps provision of each element to specialists
- the charging bases are fundamentally different
- different elements can be delivered to different timelines
The programme’s intention is to deliver an identity service under the structure of the UK digital identity and attribute trust framework. We expect the trust framework to be available ahead of the planned launch of the dashboard ecosystem, however delivery of the trust framework will come after the programme has entered alpha and beta testing phases.
In the interim, to support the test phases, PDP will engage a single identity provider, which will be tasked with following the requirements defined for the full solution.
We will procure the interim provider by the end of 2021 and integrate it with the rest of the central digital architecture in spring 2022.
A central identity service
We will use a central identity service to support all parties equally across the ecosystem and provide confidence in the use of pensions dashboards.
Incorporating the identity service within the core architecture ensures that users will complete their identity verification in a consistent and controlled manner. PDP will procure a service operating to a defined set of standards, enabling users to confirm their identity only when they are looking to request information on their pensions.
Dashboard providers will have the option to use the central identity service as their logon process should they wish to, so the central architecture can rely on the verified identity from the dashboard itself.
Considerations around the structure of the identity service
Our approach to identity needs to work for both initial dashboards and allow scope for development in the longer term. So the programme has been focussing on the structure of the service, ahead of any decision on the how to engage providers in the run-up to procurement.
Our primary considerations are:
- connectivity – the manner of connection and the number of connections required
- consumer choice – the solution must resonate with consumers, so they can recognise and trust an identity provider
- inclusivity – we need to provide access to as broad a cross section of the public as possible
- standards – it must meet defined standards but be sufficiently flexible should additional services, such as transactional capability, be added in due course
Other considerations include:
- how providers can create and manage user accounts
- the level of interoperability of the identity solution in the future ie how easily it can be used across networks and other programmes
- liability – who is responsible should something go wrong. We will look to align this with the liability model, which applies to the rest of the central digital architecture
- governance – which standards of accessibility and quality management will apply
- data privacy and data protection – what safeguards and standards will apply
- certification and audit – what evidence will we require to ensure identity providers are complying to the required standards
- security model – suppliers will need to follow best practice for encryption and cryptographic techniques
Integration approach
There are a number of different approaches that we could take to integrate the identity service into the central ecosystem, but we have considered three as part of the proposition.
Some of the key considerations included in our assessment are:
- consumer choice – the programme need to be mindful that the solution resonates with consumers and they can recognise and trust an identity provider
- inclusivity – any solution that we put in place, must have a focus on enabling as broad a cross section of the public as possible. This is not the same as verifying identity for all, but at least enabling all (or nearly all) to complete the verification process
- standards – identity must support standards as defined but be sufficiently flexible should additional services, such as transactional capability, be added in due course
- connectivity – this is relevant in terms of the manner of connection and the number of connections required
| Approach | Summary | Pros | Cons |
|---|---|---|---|
| Single identity provider (IDP), single connection | The simplest approach is to engage a single identity provider and integrate with them directly. The identity can be proven to the defined standard |
|
|
| Multiple identity providers, directly connected | As an extension of the above model, PDP engages multiple IDPs working to a single standard |
|
|
| Multiple identity providers, broker model | PDP engages a hub provider that provides access to multiple IDPs |
|
|
Creating and managing users
The way in which providers can create and manage user accounts will factor into PDP’s thinking. PDP needs identity providers to create a reusable digital identity.
This means that users will need to reauthenticate periodically, so the identity provider will need to establish an account for the user.
Linking the verified identity to authenticators (as mandated in the GPG 44 standards) means the identity provider effectively creates a user account.
Identity providers will need to advise users that they are creating an account on their behalf and manage users accounts in accordance with industry norms.
The programme’s requirements will mandate that the providers have means to suspend, close, recover and make changes to accounts.
The identity provider will be required to suspend an account before it is closed.
If changes are made to a digital identity, the identity provider will be required to notify the user through independent means, similarly if a request to close an account is made.
Inclusivity
One of the key challenges faced by all identity services is to ensure that all everyone can use their service.
Within the scope of the dashboard programme, the structure of the identity service must not present the anticipated demographic with disproportionate barriers to access. However, there needs to be a balance and inclusivity cannot come at the expense of the integrity and security of the solution.
We will require identity providers to evidence the steps that they are taking to promote and ensure inclusivity. However, the combination of identity providers in the full solution is equally important.
We need to keep in mind that the scope of the dashboard programme is to deliver online access to pension information and that, in itself, may exclude some users. Nevertheless, we should still focus on inclusivity.
The primary focus of inclusivity, from the programme’s perspective, needs to be those users that can access services online, but may not have access to the ‘normal’ evidence required by many identity providers, such as government issued documents, or have limited credit history.
We will measure identity providers on both their intent towards inclusivity and their achievement against that intent.
Interoperability
One of the key benefits of the trust framework that PDP proposes to use, is that it sets the principles under which interoperability can work.
By having the same governance structure and operating to common guidelines, schemes will be able to trust identities created within other schemes.
Interoperability provides the dashboard programme with the benefit of being able to accept identities created for other services, provided the scheme rules and standards are acceptable.
This will have the anticipated benefit of providing consumers with the ability to reuse identities and offsetting the cost of verification for the programme.
We anticipate that identities used across schemes will attract some form of cost offset but at this stage, it is not clear what that level of cross charging would be.
The programme will maintain engagement with DCMS on the trust framework with a view to supporting any interoperable services when they become available.
Liability
Liability within an identity framework has always been a difficult issue to overcome. It was one of the main reasons for GOV.UK Verify not to be adopted commercially.
The UK digital identity and attribute trust framework has a provision to further review the needs of a liability model aligned with governance provision.
Within the scope of the identity service, we are looking at the provisions incorporated within the liability model set out for the architecture.
Digital architecture suppliers (including the identity service) should indemnify other digital architecture suppliers for losses or liability findings where another supplier has contributed/caused this liability, because they have failed to provide dashboard services.
Disputes should be managed using conventional contractual escalation norms:
- allowing the parties to resolve themselves;
- appoint an arbitrator;
- or, refer the issue to court.
This indemnity framework should be supported by standard conventional contractual provisions:
- conduct of claim;
- claim disclosure/transparency;
- and supportive conduct provisions.
Further alignment with the liability model from the digital identity and attribute trust framework will take place as the scope of that move forward.
Governance
Accessibility
All elements of the central architecture are required to support accessibility standards, including the identity service.
The identity service, alongside the other services, will be required to adhere to Web Content Accessibility Guidelines (WCAG) 2.1.
WCAG defines how web content can be accessible to people with disabilities, including visual, auditory, physical, speech, cognitive, language, learning and neurological disabilities.
Alongside this, the identity service will need to be compliant with all aspects of the Equality Act 2010.
Staff and resources
The programme will not have any direct responsibility for staff and resources employed within the identity service.
The expectation is that suppliers within the identity service have the adequate structure in place to support their service proposition.
Quality management
Quality of service provision is of paramount importance to the whole ecosystem.
Suppliers to the identity service will be expected to follow an industry recognised quality management standard, such as ISO9001.
They will be expected to set out:
- individual responsibilities
- standards followed
- objectives and how they will be measured
- plans for continuous improvement
Data privacy and data protection
Provision of an identity service is dependent on the provision and validation of personal information, whether that is through documentary or biometric evidence.
The risk posed by inappropriate disclosure of personal information inside or outside the ecosystem is considerable. The impact on an individual’s financial wellbeing should not be understated.
As a consequence the programme will be looking to ensure safeguards are in place to protect data and ensure minimum standards are applied.
All providers within the identity service will be required to demonstrate the key elements of the Data Protection Act 2018 by applying data protection by design principles.
Aligned with this they will be required to have a privacy framework meeting an industry recognised standard such as:
- BS 10012:2017 from the BSI (British Standards Institution)
- ISO/IEC 27701:2019 from the ISO (International Organization for Standardisation)
Fraud management
Fraud prevention is a key aspect of the programme and the identity service is no exception.
There is an expectation that the identity service provider/s follow best practice guidance on fraud management.
While not seeking to be prescriptive, we would recommend that suppliers follow examples of approaches such as:
- guidance from the Chartered Institute of Public Finance and Accountancy (CIPFA)
- Government Functional Standard GovS 013: Counter fraud
- Government Internal Audit Agency’s standards
Participants in the identity service will be required to provide evidence of their approach.
Certification and audit
To ensure that identity providers operate within the scope of our defined standards, the programme will need to evidence that they are complying.
Under GOV.UK Verify, certification was provided by tScheme, based on a series of profiles that matched the required levels of authentication.
With the planned decommissioning of GOV.UK Verify and the reduction in the number of assigned identity providers, it is unclear whether the relationship with tScheme will continue.
The UK digital identity and attribute trust framework, is in the process of defining the guidelines for certification. Under the trust framework, the Department for Culture Media and Sport (DCMS) will introduce Trust Marks to denote those firms that have been certified.
DCMS will manage the process of certification under the trust framework, however the procedure for certifying will be overseen by UKAS, which will accredit certification and audit partners.
The guidelines are currently in development and implementation of the full procedures will not take place until after PDP has begun its identity service procurement.
Proposal
DCMS will develop a set of requirements, against which we can ask potential providers to self-certify during the bid process.
During the initial (alpha) testing phase, the programme will work with DCMS as it develops its approach, with a view to adopting the trust framework approach when the service is in operation.
We can apply this approach whether the identity service is part of an existing scheme under the trust framework or as an independent scheme in its own right.
In the event that the trust framework does not launch in time, we may require an alternate approach, however continued engagement with DCMS will provide a solution.
As part of the ongoing support of the identity service, once certified, providers will need to undertake periodic assessment, demonstrating continued adherence to the standards.
In line with certification, the structures put in place by the trust framework should support ongoing audit.
Security model
Encryption
Suppliers within the identity service will be required to follow industry standards and best practice for encryption and cryptographic techniques. We propose that these should follow National Institute of Standards and Technology (NIST) standards:
- FIPS 140-3
- SP 800-175B
- SP 800-67
Additionally, we will require providers to follow National Cyber Security Centre (NCSC) guidance on:
- using IPsec to protect data
- using TLS to protect data
Further, we will expect providers to have:
- an encryption and cryptographic controls policy document
- a communications security (COMSEC) reporting policy that explains how you’ll respond to any suspected or actual attacks
Information Management and Security
Suppliers must have an information management system that follows an industry standard, such as ISO/IEC 27001:2017.
An information management system is a collection of documents that will need to explain:
- why the organisation needs to keep information it keeps
- how they create, organise and store information
- who has access to the information
- how they share information (including why it’s shared, who it’s shared with, how often it’s shared, what format it’s in and how it’s protected)
- how information is archived
Providers will also need to demonstrate that they documented:
- technical controls
- organisational controls
- physical security controls
Data management
Suppliers must have a data management policy that explains how they create, obtain, transform, share, protect, document and preserve data. It should include:
- file naming conventions
- how metadata is created
- how to ensure the viability of data
- how data is proven to be accurate and complete
- how data is maintained and secured
The data management policy must cover the full data lifecycle. It should explain how architectures, policies, practices and procedures are implemented and maintained.
Risk management
Suppliers must have a risk management framework that follows the latest version of an industry standards, such as:
- ISO/IEC 27005:2018
- ISO 31000:2018
Whichever standard is followed, the risk management framework must include guidance about how to:
- identify and assess risks to the organisation and users
- measure how effective processes are at managing risks
- compare identified risks to the established risk criteria
- monitor and report risks
- measure residual risk
- implement a risk strategy
- protect your organisation from internal risks, including writing a bribery and corruption policy