Data protection impact assessment: PDP central digital architecture and related services

1. Name and purpose of process

This DPIA concerns the processing of personal data by the Money and Pensions Service (MaPS) in accordance with its function to deliver the Pensions Dashboards Programme (PDP), building and running the central digital architecture (CDA) and related services that make pensions dashboards possible, and connecting pension providers and schemes and dashboards to it. It does not cover MaPS’s other dashboard function, the provision of the MoneyHelper public service pensions dashboard, which will be covered in a separate DPIA.

MaPS will publish supporting privacy notices.

1.1. Background

Pensions dashboards are an innovative digital infrastructure development. They connect individual data subjects to their pensions and allow them to find and view information about their pensions in one secure place online. This includes information on their State Pension, occupational pensions and personal pensions, including accrued values and the estimated income they could provide in retirement. Data subjects will always be in control of how they access their pensions information.

The CDA makes dashboards possible by enabling individual data subjects to:

• search for their pensions using personal identity and biographical data (‘find’ data)
• be matched to their pensions by pension providers, schemes and the Department for Work and Pensions (DWP)
• view information about their pensions

Dashboards must be either:

• the MoneyHelper dashboard (provided by MaPS)
• a private sector dashboard (meeting the conditions in the Regulations to be a qualifying pensions dashboards service and authorised by the Financial Conduct Authority (FCA) to undertake the regulated activity under the Financial Services and Markets Act 2000 (Regulated Activities) Order 2001 and subject to FCA Rules)

An individual data subject’s personal data will be processed by the CDA to issue the search for a user’s pensions, called a ‘find request’. The find data will be transmitted to pension providers and schemes to find their occupational and personal pensions, as well as to DWP to find their State Pension record. Pension providers, schemes, and DWP will use this find data to search against internal records to match an individual data subject to their pensions.

This is not the only way in which individual data subjects may find and view pensions information. Pension providers and schemes are still under routine and mandated disclosure obligations in respect of the data subject, and individuals may still contact their pension provider, scheme or the DWP directly through existing channels. There is also the option of using DWP’s ‘find pension contact details’ service to track down lost pensions. However, the tracing service only gives the name of the pension provider or scheme and not the details of their pensions. The individual data subject would then have to contact the pension provider or the scheme directly to obtain that information.

For each matched pension, a code (a ‘pension identifier’, or PeI) for that pension is registered by pension providers and schemes and DWP and stored at the CDA. This enables individual data subjects to request information for these pensions to view on their dashboard.

The duties that apply to pension providers and schemes and dashboards derive from the Pensions Dashboards Regulations 2022 and the Pensions Dashboards (No. 2) Regulations (Northern Ireland) 2023) (hereafter ‘Regulations’) and the Rules of the Financial Conduct Authority (FCA) (see PS22/12: Pensions Dashboards rules for pension providers) (hereafter ‘Rules’).

1.2. The central digital architecture (CDA)

The CDA comprises the central infrastructure, interfaces and services needed to operate the service MaPS is providing. The components of the CDA that are subject to this DPIA are the:

• pension finder service
• consent and authorisation service
• governance register

More information on how the ecosystem components work and interact with each other can be found on the pensions dashboards ecosystem page.

How the CDA components process data:

1.3. CDA suppliers

The pension finder service, consent and authorisation service, and governance register are provided by the CDA suppliers, Capgemini and Origo. Capgemini is the prime contractor, and Origo is the sub-contractor who is undertaking the technological build of the CDA. The CDA suppliers are data processors, and MaPS is their data controller. Capgemini is subject to a data processing agreement with MaPS dated 2 September 2021. Origo is the sub-processor and is subject to a contract with Capgemini.

Further sub-processors involved in the processing of data that is subject to this DPIA are:

• Amazon Web Services Cloud (hosting the CDA platform and CDA audit logs)
• ForgeRock (hosting the consent and authorisation service and processing globally unique identifiers (GUIDs))
• Salesforce Cloud (connection portal, processing pension provider or scheme or dashboard provider key role contact information, processing individual data subject complaints)
• Atlassian (Jira service support tool, processing contact information for employees of pension providers or schemes, connecting third parties, dashboard providers and DWP raising support tickets)
• ServiceNow (IT service management tool, processing contact information for employees of pension providers or schemes, connecting third parties, dashboard providers and DWP raising technical queries, processing individual data subject complaints)

1.4. Other pensions dashboards ecosystem participants as independent controllers

MaPS is using the government’s GOV.UK One Login identity service to verify data subjects’ identity. As a result of successful identity verification, GOV.UK One Login also provides verified data attributes for a data subject for the search for their pensions. GOV.UK One Login is also used to verify the identities of connecting party employees as part of the process of connecting to the CDA. GOV.UK One Login will therefore process data subjects’ data to enable identity verification. The individual data subject will be referred to GOV.UK One Login and the verified information will be returned by GOV.UK One Login to the consent and authorisation service. The identity service also provides the mechanisms for reauthentication, which saves the individual data subject re-verifying their identity on each return occasion and minimises the use of personal identity data.

GOV.UK One Login is out of the scope of this DPIA but covered here for completeness. GOV.UK One Login is an independent controller for all the data processed by it. MaPS is an independent controller in respect of the identity attributes returned to the consent and authorisation service by One Login. GOV.UK One Login is subject to a memorandum of understanding (MoU) with MaPS dated 23 July 2024. GOV.UK One Login is responsible for its own DPIA.

Pension providers and schemes will also be responsible for putting in place their own DPIAs. They will be independent controllers in respect of:

• their members’ pensions data
• find data for individual data subjects they receive from the pension finder service in the form of find requests and must process to match against, in accordance with their legislative duties
• PeIs they create for found pensions in accordance with their duties

Pension providers and schemes will remain as data controllers even when using third parties such as administrators or software providers to connect, as the dashboards duties apply to the providers or schemes and they will be responsible for any other processors processing data on their behalf. The third party will be their data processor.

DWP is an independent data controller in respect of matching data subjects to their State Pension records and returning State Pension information. DWP has its own DPIA in respect of its dashboards policy and in respect of its provision of State Pension information.

MaPS has a separate DPIA in respect of its public service MoneyHelper pensions dashboard.

Private sector pensions dashboards will similarly need to put in place their own DPIAs.

2. Data processing workflow: Processing of an individual data subject’s data through the end-to-end dashboards service

An individual data subject chooses to use a dashboard to find their pensions. This involves gathering their pensions information from multiple sources and displaying it on their chosen dashboard. The CDA supports this process. In providing the CDA, MaPS undertakes the operationally required processes.

The individual data subject begins at the dashboard, where they are redirected to the CDA user interface. They begin by verifying their identity with GOV.UK One Login. As a result of successful identity verification, they are returned to the CDA user interface. An identifier is generated by One Login which represents the individual data subject’s verified identity. This is then hashed by the consent and authorisation service to create a pseudonymised user account identifier (Account ID) which is held at the consent and authorisation service and used for the purpose of re-authenticating the individual data subject’s identity when they use and return to the consent and authorisation service. Returned to the consent and authorisation service having verified their identity, the data subject mayadd self-asserted data to complement the data attributes provided by GOV.UK One Login.

The data subject’s ‘find’ data is then sent to DWP and all connected pension providers and schemes, who use it to match the individual data subject to any pensions they may have. Many pension providers and schemes will connect to the pensions dashboards ecosystem via a third party, such as an integrated service provider (ISP) or third-party administrator (TPA). An individual data subject’s find data is, therefore, in practice distributed to all find endpoints, rather than to all pension providers and schemes.

2.1. Find requests

A find request consists of limited personal biographical and identity data attributes, issued to pension providers, schemes and DWP for the purpose of matching and locating a user’s pensions. It contains data provided by GOV.UK One Login and data input directly by the data subject. The data subject will need to verify the accuracy of the data in the find request before it is issued. This processing of the find data to distribute a find request is undertaken by MaPS on the lawful basis of public task (see section 7 below).

Data in the find request is not retained within the CDA beyond the issuing of the find request. The sending of the find request is the end of MaPS’s processing of this data. In the event of a find endpoint outage at a receiving pension provider, scheme, third party or DWP, the pension finder service retries the find request periodically. In this case, the data would continue to be processed by the pension finder service for up to a maximum of 38 seconds until either the find request is received and acknowledged by the find endpoint or the endpoint is deemed down and the find request expires. Once the pension finder service has sent the find data to pension providers and schemes and DWP, and they have acknowledged receipt, it only exists at the receiving pension providers, schemes (or their third parties) and DWP.

Pension providers and schemes then process the find data in accordance with their duties under the Regulations and Rules to check whether they match any member records, under the legal obligation lawful basis, as independent data controllers. DWP similarly processes the find data to attempt to match the data subject to their State Pension record.

2.2. Creation and registration of a pension identifier (PeI)

Each separate pension arrangement identified as a match or possible match against the find request by a pension provider, scheme or DWP is registered with the CDA by the pension provider, scheme or DWP, in the form of a PeI. This is an identifier for a specific pension and is generated by a pension provider, scheme or DWP, in accordance with the PDP technical standards. It is registered by the pension provider or scheme, in accordance with duties under the Regulations and Rules, or by DWP, with the consent and authorisation service against the data subject’s user account. This is identified by a pseudonymised identifier which represents the data subject’s verified identity.

A PeI is independent of any dashboard. It can only be registered, de-registered, or its registration changed, by the entity that registered it. Once registered, a PeI is stored at the CDA against the individual data subject’s user account, unless it is de-registered, or the individual data subject chooses to entirely delete their CDA user account, thereby removing all their data including registered PeIs.

The Regulations require dashboards to retrieve the PeI if the consent of the user has been provided. The dashboard uses an individual data subject’s PeIs, retrieved from the consent and authorisation service with their consent, to request view data from pension providers and schemes, and State Pension information from DWP. This view request is direct from the dashboard to the pension provider’s or scheme’s or DWP’s view endpoint and does not come through the CDA. Dashboards will retrieve and process these PeIs as independent data controllers on the legal obligation lawful basis.

2.3. View requests and view data returned to the dashboard

View data is outside the scope of this DPIA, as MaPS does not process this data in respect of its functions providing the CDA, but rather in its capacity as the provider of the MoneyHelper pensions dashboard. This processing by MaPS, subject to a separate DPIA, involves the processing of information about a data subject’s pensions, including administrative information, accrued values and projected values.

Where a find request results in a positive match (including a possible match) by the pension provider, scheme or DWP, with the user’s consent, the data subject’s dashboard retrieves the registered PeIs from the data subject’s user account at the consent and authorisation service. This enables the dashboard to make a view request. That is, to request pension information from the provider, scheme or DWP for display to the data subject on their dashboard.

Pension providers and schemes hold the view data that is required by the legislation to be returned to dashboards for their members as independent data controllers, as does DWP for State Pension information. Upon receipt of a view request, the pension provider, scheme or DWP’s view interface checks the individual data subject has consented to their view data being sent to the dashboard that issued the view request. It checks the tokens received in the view request against the individual data subject’s authorisations as stored at the consent and authorisation service, using an API. If the view request is authorised (it contains valid tokens representing the authorisations of the data subject), they must provide the view data. The provider or scheme will process the view request under legal obligation. If the view request is not accompanied with valid tokens, the view interface coordinates with the consent and authorisation service to initiate the authorisation process to obtain a new valid token.

DWP will similarly check the authorisation of the request for State Pension information and release State Pension information back to the dashboard. Pension providers, schemes, and DWP will be processing this view data as independent data controllers.

The consent and authorisation service processes view authorisation checks as an independent data controller under the public task lawful basis.

Authorised view requests result in the view data being transmitted from the pension provider or scheme, and State Pension information from DWP, back to the requesting dashboard. The dashboard then displays this data in accordance with the Regulations including in compliance with MaPS’s design standards. The dashboard only stores the data temporarily. The dashboard is not permitted to store the data beyond temporary caching for the sole purpose of display to the user in a single session. The dashboard processes this data as an independent data controller under legal obligation.

If the dashboard operates a user account, it may persist the tokens issued by the consent and authorisation service at the individual data subject’s dashboard account, to decrease the friction for subsequent view requests.

2.4. Information to support regulators’ functions

MaPS may need to process and share the individual data subject’s personal data with The Pensions Regulator (TPR) and FCA so they can discharge their regulatory functions, to supervise pension providers and schemes’ and dashboard providers’ compliance with their legislative duties. Where MaPS needs to do this, only the minimum amount of data needed will be shared under the data sharing agreement that will be put in place with both.

3. Description of the data subjects that the data processing refers to

Data subjects will be those individuals who opt to use pensions dashboards to find and view their pensions. This includes volunteer test users recruited by or on behalf of MaPS for the purpose of testing the CDA and the end-to-end user experience, as well as members of the public using the service once the legislative framework is in place.

In this DPIA, individual users of the CDA that makes dashboards possible are referred to as ‘individual data subjects’. The CDA enables these individual data subjects to find their pensions and view information about their pensions on a dashboard.

There are other data subjects:

• employees of pension providers and schemes or their third-party connection providers managing connection on their behalf
• employees of DWP managing State Pension connection
• employees of dashboard providers
• employees of the regulators, accessing reporting data to support regulatory functions

These providers will need to provide contact details for named representatives who will be points of contact with the CDA in respect of the pension providers and schemes complying with their legal duties. The CDA supplier will need to process these details. PDP will also verify the identities of the initial contact in connecting organisations undertaking the pre-registration process, primary business contacts and primary technical contacts. Any industry participant employees raising IT or general helpdesk queries/support tickets on ServiceNow/Jira will similarly provide names and contact details.

When referring specifically to these other data subjects, it is made clear in this DPIA.

4. Description of the personal data processed within the CDA and by MaPS to provide its pensions dashboards ecosystem functions

To enable the CDA to work, the CDA suppliers will process the following personal data:

4.1. Pseudonymised user account identifiers

Every individual data subject using the service has an ‘account’ at the CDA, linked to their identity as verified by GOV.UK One Login, which is identified by pseudonymised identifiers:

• PID: Having verified the data subject’s identity, GOV.UK One Login returns to the CDA a pseudonymised token representing the data subject’s identity. This is not stored by the CDA, but is hashed to create a CDA Account ID.
• Account ID: An internal identifier of the user within the CDA, derived from a hash of the PID.
• UserGUID: This is a hash in turn of the Account ID and is the identifier shared with the dashboard to enable it to obtain registered PeIs for the user’s found pensions.
• Find correlation ID: Each find request issued by the pension finder service to pension providers and schemes and DWP contains a pseudonymised unique identifier to link find requests that are issued in relation to a particular individual data subject, consistent for that data subject across multiple find requests. This allows pension providers and schemes and DWP to identify where repeated find requests are issued in relation to the same individual data subject. It enables them, upon identifying a possible match, to see if it relates to a user who previously had been possibly matched but was resolved not to be a match, thus preventing a continuous possible match cycle. This identifier is unique per individual data subject and per each connecting organisation (rather than being common across all find endpoints receiving find requests in respect of a particular individual). It is generated by hashing the account ID, combined with the data provider code that identifies the pension provider, scheme, ISP or TPA that receives the find request. This is generated afresh each time a find request is issued in respect of an individual data subject and is not stored at the CDA.

4.2. Find data

Each find request, issued by the pension finder service for an individual data subject to locate their pensions, contains find data. This is individual data subjects’ personal biographical and identity data, and comprises verified identity attributes and other information checked as part of the identity verification process, provided to the consent and authorisation service by GOV.UK One Login, and additional information collected directly from data subjects (‘self-asserted’) at the consent and authorisation service. The data standards detail the scope of potential find data attributes. This is distributed to pension providers, schemes, and DWP in the form of the user token – a JSON web token which encapsulates the find data. The technical standards define how it is to be used, and stipulate that the token is issued for the sole purpose of triggering the find process and its contents must not be persisted by the pension provider or scheme if: (a) the pension provider/scheme determines that the token does not relate to any relevant member of the scheme; (b) if a possible match is registered but the dashboard user does not make contact within 30 days; or (c) a possible match is registered and the user makes contact but the pension provider or scheme is not able to resolve the possible match within such time as may be reasonably allowed by the provider or scheme.

4.3. PeIs

A PeI is an identifier of a specific pension matched (or possibly matched) to the individual data subject in response to a find request. Its format is a text string in the form of a uniform resource name (URN) and provides a pointer to the pension asset. It is capable of being dereferenced by a pensions dashboard and resolved into a URL, which provides the view endpoint which can serve the pension details associated with the PeI.

PeIs are created by and registered with the CDA by the pension provider or scheme or DWP that identified the match or possible match against a find request. Once registered, the PeI is stored at the consent and authorisation service against the individual data subject’s account, and is used to enable the user to request view data and State Pension information to their dashboard.

Although the PeI is personally identifiable information, it does not on its own identify an individual data subject. It contains unique identifiers for:

1. the specific pension asset (asset identifier GUID)
2. the pension provider’s/scheme’s/DWP’s view endpoint to send a view request to retrieve pension information (holdername GUID).

PeIs alone do not provide access to pensions information. PeIs only enable access to the view data as part of authorised view requests issued by the data subject to the pension provider, scheme or DWP. This happens when the PeI is accompanied by valid access control tokens confirming the individual data subject’s authorisation. These tokens are managed by the consent and authorisation service and enable the dashboard to locate the data subject’s view information at the pension provider, scheme or DWP user-managed access (UMA) Resource Server. The server at the pension provider, scheme or DWP for access-protected resources responds to view requests from the dashboard and returns the protected view data to authenticated users.

4.4. Consents/authorisations

The consent and authorisation service stores the individual data subject’s consents/authorisations at their user account. These authorisations can be managed by the individual data subject and work to:

• enable registration with the consent and authorisation service of PeIs by pension providers, schemes and DWP for any found pensions, placing PeIs under authorisation protection
• convey the individual data subject’s consent to the PeIs being disclosed to their dashboard
• convey the individual data subject’s consent to their dashboard requesting their view data
• convey the individual data subject's consent to their pension provider or scheme providing their view data to their dashboard

These authorisations are stored at the consent and authorisation service under a profile registered against a pseudonymised hashed identifier which represents the individual data subject’s verified identity (the Account ID – see appendix). Upon the data subject returning to the consent and authorisation service, this hashed identifier is used to correlate with the identifier produced by the identity service, enabling the individual data subject to return to their own account at the consent and authorisation service.

4.5. Cryptographic tokens and identifiers

Cryptographic tokens are used to represent the individual data subject’s authorisations and are created, encrypted, and decrypted by the CDA and used to authorise retrieval of view data to authenticated individual data subjects. These tokens and identifiers are personally identifiable information, although they are meaningless outside the dashboards ecosystem. These tokens and identifiers are processed by the CDA for various purposes. A detailed explanation of these tokens and identifiers and how they are used in find and view processes is included in appendix A.

4.6. Enquiries and complaints about the CDA

MaPS may receive enquiries and complaints from dashboard users relating to the CDA service. MaPS will need to consider the issue and circumstances and be able to contact the individual to get more information and liaise with them about progress and outcome. This involves processing of personal data.

4.7. Industry personnel identity verification and contact details

Pension providers and schemes (or their third parties managing connection on their behalf), DWP, and dashboards provide contact details for selected staff members to connect to the CDA and manage their connection to the dashboards ecosystem. Names and contact information will be processed on the connection portal (Salesforce) for these industry data subjects. As part of the pre-registration process that any organisation connecting to the ecosystem must go through, identity checks via GOV.UK One Login will be undertaken for the initial contact undertaking the pre-registration process, the primary business contacts (if different to the initial contact) and the primary technical contacts, including when new primary business or primary technical contacts are added. The identity check validates both the identity of the individual and their organisation email address. Industry participant employee personal data is also processed by MaPS and CDA suppliers in relation to IT support and general helpdesk queries logged on ServiceNow or Jira.

To ensure only regulated pension providers and schemes or third parties genuinely acting for them can connect to the pensions dashboards ecosystem, when an organisation other than a pension provider or scheme first connects, MaPS checks with the pension provider or scheme on whose behalf they are claiming to act. MaPS will receive personal contact information from TPR or FCA for the primary dashboard contact (for an occupational pension scheme) or for the person performing the compliance oversight function (SMF-16) for a personal pension provider. This will be used to contact the pension provider or scheme to check that the third party purporting to be acting on their behalf is genuinely doing so and therefore has a legitimate reason to connect. This processing of trustee/SMF-16 data will be covered by data sharing agreements between MaPS and TPR and between MaPS and FCA.

4.8. Supporting regulator functions

MaPS may need to process and share the individual data subject’s personal data with TPR and FCA so they can discharge their regulatory functions, to supervise pension providers’ and schemes’ and dashboard providers’ compliance with their legislative duties. Where MaPS needs to do this, only the minimum amount of data needed will be shared under the data sharing agreement that will be put in place with both.

5. Description of the special category data

No special category data will be collected or processed.

6. Identity of controller of personal data

MaPS will be an independent data controller for all the personal data detailed in section 4 and processed within the CDA, as set out below. The CDA suppliers will be a processor of data processed by them on MaPS’s behalf.

6.1. Pseudonymised user account identifiers

When the CDA processes these identifiers to maintain the user account at the CDA to facilitate the user to search for their pensions and view their pensions information, MaPS is determining the means and purpose of the processing in accordance with its function to make dashboards possible and is, therefore, an independent data controller in relation to this processing.

• PID: GOV.UK One Login, provided by the Government Digital Service (GDS), part of the Department for Science, Innovation, and Technology, shares the pseudonymised token representing the user’s verified identity (the PID) with MaPS as an independent data controller, as it is determining the means and purpose of this processing in the execution of its function to allow individuals to sign in to government services. MaPS processes the same identifier temporarily and retains the hash of this identifier in the exercise of its own functions in respect of delivery of the pensions dashboards digital architecture.
• Account ID: Internal to the CDA; MaPS is determining the means and purposes.
• UserGuid: When MaPS uses this within the CDA, it is determining the means and purposes of the processing. When used by the dashboard to retrieve registered PeIs from the CDA, the dashboard processes this in accordance with its legislative duties to retrieve PeIs and is therefore processing under a legal obligation as an independent data controller.
• Find correlation ID: When the CDA creates this unique identifier and distributes it to pension providers and schemes alongside the find data, MaPS is determining the means and purpose of the processing in accordance with its function to make dashboards possible and is, therefore, an independent data controller in relation to this processing. When processed by the pension provider or scheme to comply with legislative duties, they are an independent data controller.

6.2. Find data

When the CDA processes this personal data to put together a find request for the user and distribute it to pension providers and schemes, MaPS is determining the means and purpose of the processing in accordance with its function to make dashboards possible and is, therefore, an independent data controller in relation to this processing. MaPS’s processing of the find data stops at the point the find request is distributed to connected pension providers, schemes and DWP.

6.3. PeIs

During the pension registration phase for any matched pensions, the pension provider, scheme or DWP is an independent data controller in respect of creating and registering the PeI. For pension providers and schemes, this will be under a legal obligation. For DWP this will be on the basis of public task.

MaPS will be processing the registered PeI, as an independent data controller, in accordance with our function to establish and run the CDA to make dashboards possible. The PeI will be stored in the data subject’s user account at the consent and authorisation service and shared with the user’s chosen dashboard. Once the dashboard has retrieved the PeI, the dashboard will process it, as another independent data controller, by calling the relevant pension provider/scheme’s or DWP’s view interface as part of the dashboard’s legal obligations to retrieve the user’s view data.

6.4. Consents/authorisation policies

When the CDA undertakes the processing of these items, MaPS is determining the means and purpose of the processing and is, therefore, the data controller.

6.5. Cryptographic tokens and pseudonymised identifiers

When the CDA undertakes the processing of these tokens and identifiers, MaPS is determining the means and purpose of the processing and is, therefore, the data controller. This is regardless of whether they are generated or received by the CDA. Once tokens and identifiers are being processed by the dashboard, pension providers, schemes or DWP, MaPS’s data controller obligations will end. The dashboard, pension provider, scheme or DWP will then process the tokens or identifiers as a data controller. For dashboards, pension providers or schemes this will be under a legal obligation created by a combination of the Regulations, Rules and the MaPS mandatory standards.

6.6. Enquiries and complaints relating to the CDA

MaPS will be determining the means and purpose of the processing and is, therefore, the data controller.

6.7. Industry identity verification and contact details

When the CDA undertakes the processing of these items, MaPS is determining the means and purpose of the processing and is, therefore, the data controller.

6.8. Regulatory information

When the CDA undertakes the processing of personal data to support regulatory functions, MaPS is determining the means and purpose of the processing and is, therefore, the data controller.

7. Legal basis for processing information

MaPS’s lawful basis for all processing of personal data within the CDA and in delivery of its related pensions dashboard ecosystem functions is public task. MaPS’s functions through the CDA facilitate pension providers’ and schemes’ and dashboards’ compliance with their dashboards obligations to enable individual data subjects to find their pensions.

This processing of personal data is necessary for the performance of a task carried out in the public interest or in the exercise of official authority vested in the controller (UK GDPR Article 6(1)(e)). Without this processing, MaPS could not fulfil its functions in respect of the dashboards ecosystem and deliver the CDA and associated services – which is the implementation of those functions – upon which pensions dashboards depend.

Pensions dashboards are a public good with a wide public benefit attached. Their success is an important government policy, designed to benefit the UK population’s engagement with pensions and support informed retirement planning.

The establishment of a viable CDA to deliver MaPS’s functions in respect of the pensions dashboards ecosystem similarly requires testing of the CDA and related services to ensure they are fit for purpose and deliver a good user experience. MaPS’s processing of test users’ personal data is necessary for MaPS’s delivery of a viable CDA, the provision of which is the exercise of its official authority.

The Regulations and Rules set out in law MaPS’s functions in respect of providing the CDA to facilitate pensions dashboards services. These are MaPS’s functions relating to data subjects, dashboards, pension providers and schemes and DWP, which are implemented through the CDA and associated services and help to achieve the government’s policy, whilst protecting data subjects. MaPS’s processing of personal data is necessary to these functions:

• individual data subjects must be passed from dashboards to MaPS. MaPS must undertake some identity verification steps, process the find request and issue it to all pension providers, schemes and DWP as well as capture the individual data subject’s dashboard choices
• pension providers and schemes must:
• register with MaPS and connect to the CDA provided by MaPS (DWP will also connect for State Pension purposes)
• receive find requests from MaPS
• register found pensions with MaPS in the form of PeIs, and de-register PeIs where pension assets fall out of scope
• check the authorisation of view requests with MaPS
• report operational and management information to MaPS
• provide contact details to MaPS when they connect to the CDA (under the Regulations and Rules) for the purpose of connection and managing their ongoing connection

Collection, generation, and processing of find data, data subject authorisation policies, PeIs and tokens are required to deliver these functions, as well as monitor performance and behaviours.

Dashboard providers must:

• register with MaPS and connect to the MaPS digital architecture
• check consent of the user and retrieve PeIs from MaPS for users
• issue view requests
• display view data in accordance with MaPS design standards
• report operational and management information to MaPS

Collection, generation, and processing of PeIs, data subject authorisation policies, and tokens are required to deliver these functions, as well as monitor performance and behaviours.

Under the Financial Claims and Guidance Act 2018 and the Regulations, MaPS has statutory gateways in place with both FCA and TPR. MaPS may share information with either body where they have made a request and the request relates to their statutory functions.

Collection and processing of a complaint is necessary for MaPS to provide the CDA service and investigate complaints of inadequate service and ensure there is sufficient consumer protection should MaPS/CDA supplier not provide the service required by MaPS’s functions.

7.1. Legal Basis for Special Category Information (Article 9(2))

Not applicable – no special category data collected.

8. How will the data protection principles be met?

8.1. Principle: Lawful, fair, and transparent basis

Pensions dashboards are to operate within a new legislative landscape (the Regulations and Rules) and a modified regulatory environment. Pensions dashboards are delivered against the backdrop of a lawful framework set up explicitly for a clear legal purpose with a public benefit in mind.

The CDA is established by MaPS to implement its functions as per the Pensions Act 2004 sections 238A-E for “the use of facilities or services specified or of a description specified in the regulations” for pension providers, schemes and pensions dashboard providers to carry out their dashboards functions and allow individual data subjects to find and view their pensions information. Its operation is detailed by a suite of mandatory standards.

Government departments and regulators are working together to deliver and regulate dashboards within this new space.

MaPS will explain to individual data subjects how their personal data will be processed before any is submitted. This includes find data, consents, cryptographic tokens and identifiers.

MaPS will explain to industry data subjects how their personal data will be processed. This data is used to connect pension providers, schemes, DWP and dashboards.

Implementation of all the data subject’s rights will be communicated in privacy notices. Privacy notices will explain to the data subjects the boundaries of MaPS’s processing based on public task.

This DPIA will be published to provide transparency of all MaPS’s data processing in relation to its dashboards functions.

8.2. Principle: Purpose

Personal data is only collected and processed by MaPS within the CDA in relation to the overall purpose of enabling dashboards services to find individual data subjects’ pensions and display information about them in one secure place online. This includes:

• facilitating connection of pension providers and schemes (including third parties acting on their behalf) and DWP, and of dashboards
• enabling individual data subjects to verify their identity and share their find data with pension providers, schemes and DWP for the purpose of pension matching
• enabling registration of found pensions as PeIs
• enabling the dashboard to retrieve PeIs with the data subject’s consent and request the information on found pensions (view data and State Pension information) from pension providers and schemes and DWP, in line with data subject authorisation policies
• operational management of connection of pension providers and schemes, DWP, and pensions dashboards providers
• monitoring pension provider and scheme and dashboard provider performance and behaviour within the pensions dashboard ecosystem, and sharing operational and monitoring information with regulators
• dealing with any individual data subject complaints
• retaining personal data as long as operationally required in accordance with the retention schedule
• testing the CDA and related services with test users and voluntary participant pension providers and schemes, to ensure an effective service and a good user experience

Personal data will not be used within the CDA for any other purposes.

8.3. Principle: Data minimisation

The CDA does not collect more personal data than is operationally required to be able to issue a find request to pension providers, schemes and DWP for them to use to search against their internal records to identify any matching pensions.

The identity service returns only minimal verified identity attributes to the consent and authorisation service for the find function.

At the consent and authorisation service, the individual data subject will be asked to input self-asserted identity information (such as National Insurance number, previous names and addresses) for the find function. Initially, to support data minimisation, this will only be National Insurance number. Testing with and feedback from pension providers and schemes about matching will inform expansion of self-asserted data attributes that may be provided. This will be kept under review and the collection of self-asserted data from users to support matching will be proportionate to the use of the data by pension providers and schemes for matching. Minimum individual data subject authorisation policies are stored under the data subject’s account at the consent and authorisation service.

None of the identity and biographical data contained within a find request is retained by the CDA after the find request is issued, the only exception being where a pension provider or scheme find interface is temporarily offline, in which case the backoff and retry protocol is activated, which means the data could be stored at the central digital architecture for up to 38 seconds until either the find request is acknowledged by the find endpoint or the endpoint is considered down and the find request expires. There is therefore no aggregation of find data in the CDA.

The only data stored at the individual data subject’s account at the consent and authorisation service to enable dashboards to work are:

• pseudonymised cryptographic tokens representing the user’s verified identity
• PeIs registered for their pension assets that have been matched to them and registered by pension providers and schemes (including match status – i.e. whether it is a match made or possible match)
• their consents for the accessing of this information by the dashboard.

This data is held securely at the user’s consent and authorisation service account, accessible only by the user, having verified/re-authenticated their identity via GOV.UK One Login.

Wherever possible, cryptographic tokens and identifiers are used instead of the CDA storing records of the biographical data used for find requests or details of the pensions found. This is to minimise the CDA’s processing of data and ensure the CDA’s effective operation.

Employee contact details gathered for pension providers and schemes (or their third parties), DWP, and dashboard providers are the minimum required to be able to facilitate connection and to manage the ongoing connection of these parties. Other contact details from TPR and the FCA are similarly the minimum required for MaPS to carry out its functions.

In the event of an individual complaint, the minimum amount of personal data will be obtained from the individual data subject to process this complaint.

8.4. Principle: Accuracy

Verified identity attributes are provided by the identity service and verified as belonging to the data subject in line with the principles defined in the Government Digital Service’s Good Practice Guides 44 and 45. The individual data subject supplies additional non-verified personal data and will be asked to check the accuracy of this information before it is sent to pension providers, schemes and DWP in a find request.

As part of any complaints-handling function, data subjects will be asked to check the accuracy of any information they enter before it is submitted.

Pension provider, scheme, DWP, dashboard, FCA and TPR employee data subjects will be asked to check the accuracy of their contact information.

PDP technical standards set out the rules for the consistent generation of PeIs and cryptographic tokens.

8.5. Principle: Storage

No find data for individual data subjects is retained within the CDA beyond the issuing of the find request. This data is transient and only used for a one-off distribution to pension providers, schemes and DWP by the pension finder service and will not be stored. The only exception will be where receipt of a find request is not acknowledged because the find interface is temporarily offline, in which case the find request may be held for up to 38 seconds for the retry process, until either the find request is acknowledged by the find endpoint or the endpoint is considered down and the find request expires.

Only the pseudonymised tokens and identifiers to maintain the data subject’s user account and authorisations at the consent and authorisation service which enable dashboards services to operate are persisted beyond the issuing of the find request.

See section 14 for full details of the retention period rules.

8.6. Principle: Security

The pensions dashboards ecosystem security design has been developed based on National Cyber Security Centre (NCSC) best practice guidance. NCSC has advised on a set of baseline security controls for the pensions dashboards ecosystem to be implemented by MaPS in the build of the CDA, as well as by all connecting dashboards, pension providers, schemes and DWP through the standards MaPS sets. These baseline security controls include protection solutions for all network communication and encryption solutions for data in transit and at rest. NCSC has also been engaged in security design assurance.

8.6.1. Security of the MaPS CDA

MaPS and its CDA supplier have agreed a Security Management Plan which is compliant with the baseline security controls, MaPS’s ICT and security policies, and with the principles and practices of ISO/IEC 27001 and 27002. This documents the security measures to be implemented and maintained by the CDA supplier in relation to all aspects of the services and all processes associated with the CDA delivery. It documents the incident management process which handles an information security incident involving data breach, and covers reporting/identification, analysis and handling. Via the suppliers, MaPS has 24/7 security monitoring, threat detection, and incident response capabilities.

The CDA suppliers are contractually obligated to develop and implement an IT security management system to protect all aspects of the services and processes associated with the CDA. This includes premises, sites, systems and data, in compliance with the baseline security controls, and the standards in ISO/IEC 27001 and 27002. This IT security management system documents security incident management processes and response plans and vulnerability management policies. The CDA supplier will conduct tests of this system at least annually to ensure it remains fit for purpose. MaPS implements routine performance reviews, and assessments to monitor supplier adherence to contractual security and legal obligations.-

CDA suppliers are contractually bound to host all data subject personal data in the UK only, and they are subject to UK jurisdiction (including UK data protection and privacy laws).

All data at rest within the CDA will be encrypted in accordance with encryption standard AES-256 and will be subject to the retention policies (section 14). The data will be deleted at the end of the retention period.

The CDA operates under a security management system which has been certified to ISO27001 by a UKAS-registered Certification body and has an up-to-date registration. The service is accessed by a role-based access controls (RBAC) allied to unique user accounts. The AWS platform is scanned weekly by the Tenable cloud security tool - as the CDA platform is a serverless/containerised environment, the scanning compares the AWS configuration with industry best practice configuration against NIS, GDPR and IS27001 benchmarks. The outputs from these scans are reviewed by the supplier teams and fixes are put in place or mitigations discussed and agreed with MaPS’s security manager and where relevant, scan exclusions are implemented via change control.

Data subject profiles are stored within the CDA under a pseudonymised hashed identifier which obfuscates the individual data subject’s identity. To access this profile and alter any of their authorisation policies, the individual data subject must be re-authenticated at the identity service. Individual data subject information is not retained in any of the other cryptographic, pseudonymised tokens.

8.6.2. Security across the wider dashboards ecosystem

MaPS’s security standards set requirements for ecosystem participants in respect of encryption and mutual authentication for all within-ecosystem communication, independent vulnerability testing prior to connection and annually once connected, and monitoring and incident response. This security framework fosters trust among participants, assuring them that their sensitive information is protected. The code of connection (containing connection, security, service, operational, and technical standards) ensures that data transmitted across the pensions dashboards ecosystem is encrypted and safeguarded against unauthorised access.

All data in transit within the ecosystem will be protected from modification or unauthorised access, and will be encrypted implementing TLS1.2 (at a minimum). This includes identity data, access control information, PeIs, associated identifiers and tokens. All interactions between the CDA and pensions dashboards ecosystem participants will be protected by Mutual TLS (mTLS) encryption. This provides security in communications exchanges and allows ecosystem participants to communicate with and authenticate a server without any third parties being able to see or alter the content, by reciprocally establishing authentication between parties. It does this by using the public key to encrypt messages and each party’s private key to decrypt the messages.

Additionally, the code of connection requires connected organisations to undertake regular independent security assessments performed by appropriately certified assessors, further mitigating risks and enhancing the overall resilience of the ecosystem. 

The governance register restricts access to the data-sharing architecture. The governance register maintains a directory of all organisations permitted access and only allow legitimate dashboards, pension providers or schemes in. All pensions dashboards ecosystem components will need to register software with the consent and authorisation service to participate and will need appropriate key material (a public key infrastructure (PKI)) provided by the governance register. All pensions dashboards ecosystem components will need certificates to ensure connections are secure and meet the required technical standards and specifications. The CDA hosts a private certificate authority to generate the certificates and public/private key pairs for PDP ecosystem participants, which is used to create encrypted TLS communication channels, authenticate systems and API endpoints, and cryptographically sign tokens. For all ecosystem interactions, participants must present a certificate issued by the certificate authority, which confirms they are part of the ecosystem. The other party to the interaction must verify the validity of the certificate it is presented with through the interaction. To be issued by the certificate authority with the required material to inter-operate with pensions dashboards ecosystem components, parties will have to demonstrate they meet, and continue to meet, the required standards. 

9. How will MaPS ensure appropriate accountability and proportionality?

9.1. Accountability

9.1.1. Overall approach

MaPS recognises that the CDA involves the creation and processing of personal data at scale, as a result:

• MaPS has put this DPIA in place and engaged with the MaPS Data Protection Officer (DPO), lawyers, DWP and the Information Commissioner’s Office (ICO) throughout its development to ensure there is not an elevated risk to the data subjects’ personal data through protective measures
• MaPS has implemented a data protection by design and default approach throughout the CDA’s build. For example, embedding the UK GPDR principles of data minimisation, data pseudonymisation, transparency and security within the CDA’s build, as this DPIA and our contracts with the CDA suppliers make clear
• this DPIA has been subject to MaPS’s Information Assurance Group oversight
• this DPIA has been subject to an independent review by an external DPO
• MaPS will regularly benchmark this DPIA against comparable DPIAs for other organisations
• MaPS is committed to keeping this DPIA (and accountability measures) under review (at least annually) and updated as required
• MaPS is applying its existing data protection principles and processes, as well as bringing the CDA under the oversight of its DPO
• MaPS staff are regularly trained on UK GDPR issues – data protection is included in annual mandatory training
• MaPS is publishing this DPIA and privacy notices for data subjects

9.1.2. Supplier agreements

It is MaPS CDA suppliers who will be processing the data subjects’ personal data in scope of this DPIA. A written data processing agreement has been put in place with the CDA suppliers and a written memorandum of understanding with GOV.UK One Login. As well as the security measures already detailed, MaPS suppliers are required to:

• regularly test the security of the CDA
• report breaches (which MaPS would record)
• appoint DPOs
• be registered with the UK ICO
• implement appropriate technical and organisational measures to ensure and demonstrate compliance through training, controls, policies, and a regular audit
• put in place DPIA and risk assessments data flow mapping
• maintain relevant documentation and records for:
• user profiles (including authorisation policies)
• transfers to third countries
• retention schedules
• security measures

MaPS has put in place appropriate technical and organisational measures to:

• undertake routine performance reviews, and assessments to monitor suppliers’ adherence to contractual security and legal obligations
• adopt and implement proportionate data protection policies
• keep evidence of the steps we take to comply with the UK GDPR
• maintain documentation of our processing activities

9.1.3. FCA and TPR data sharing agreements

MaPS are putting in place data sharing agreements with FCA and TPR for the sharing of scheme/firm data with MaPS for the purpose of connection of pension providers and schemes and the sharing of operational and monitoring data by MaPS with regulators to support their compliance monitoring and enforcement functions. These voluntary agreements will set out a framework for the disclosure of information and define principles and procedures and the responsibilities parties owe each other..

9.1.4. Proportionality

The processing of the data subject’s personal data is a targeted and proportionate means of providing the CDA service to enable dashboards to function. The processing of data is restricted to the minimum necessary to provide this service for the individual data subject’s pensions to be found and test whether it is operating as intended and deal with any complaints.

The CDA will not be generating any more personally identifiable information than is needed to ensure the CDA’s operational effectiveness, and wherever possible makes use of pseudonymised identifiers.

The steps we are actively taking to ensure the proportionality of dashboards are subject to extensive user research, which will help to ensure data protection by design and default.

10. How will the data subject’s rights be met?

This section applies to all the data subjects: individuals, pension providers’ and schemes’ employees, as well as those who make complaints and how the pensions dashboards architecture supports these 9 rights.

10.1. The right to be informed about the collection and use of their personal data

User-tested explanations of the data processing involved in providing the service and cookie notices at the CDA for all individual data subjects when they interact first with the CDA.

Privacy notices will be available to each category of data subject whilst at the CDA and on the PDP website.

10.2. The right of access to their personal data

The individual data subject will be able to access their profile anytime at the consent and authorisation service to review their authorisation policies. The privacy notice will explain how data subjects can make a data subject access request in respect of the personal data MaPS may hold.

10.3. The right to rectification of inaccurate personal data

As only limited personal data for an individual data subject is processed by the CDA, there is little scope for rectification of data. However, in the event that data (PeIs registered, authorisations set by the user) are inaccurate, the data subject will be able to access the consent and authorisation service to review their data, delete their data, or address any inaccuracies.

Find data is not retained within the CDA. The individual data subject will be able to see the verified data provided by GOV.UK One Login, but will not be able to address any inaccuracies at the CDA. They would need to contact GOV.UK One Login to correct any of this data. This will be explained to them when interacting with the finder service.

Similarly, the individual data subject will need to address any inaccurate view data or State Pension information returned to their dashboard via the pension provider, scheme, or DWP directly and outside the pensions dashboards ecosystem.

10.4. The right to erasure of their personal data

Not applicable for public task processing by MaPS which is necessary to provide the CDA service in accordance with its statutory functions. However, the individual data subject will be able to delete their CDA account and remove all data (registered PeIs, and pseudonymised identifiers and tokens) if they wish to do so. The effect of deleting this data will be that their user account at the consent and authorisation service will be deleted and all found pensions will be deleted. Therefore, they will not be able to use pensions dashboards. This will be made clear to users at the consent and authorisation service user interface.

10.5. The right to restrict processing

This is not applicable in respect of any data subject. The CDA processing by the CDA is all necessary to provide the dashboard service.

If the individual data subject wishes to stop CDA processing, then they can delete their account, thereby deleting their data (pseudonymised tokens and identifiers and PeIs) from the CDA. This will be explained in the privacy notice.

10.6. The right to data portability

Not applicable for public task processing by MaPS in respect of its CDA functions.

10.7. The right to object

The processing of personal data as described in this DPIA is all necessary to provide the dashboard service pursuant to MaPS’s statutory functions. Data subjects have a general right to object to processing on the basis of public task. However, the right of objection is not absolute and since this processing is all necessary to enable us to exercise our statutory functions (for as long as the data subject remains a dashboard user), data subjects will not be able to object to and restrict this processing. All processing by MaPS follows from the individual data subject’s decision to use the service. Once an individual data subject has elected to use the service and their data is being processed by MaPS in accordance with its dashboards functions, should they wish to stop the processing of their data by MaPS, then they can delete their CDA account. This will be explained in the privacy notices in respect of each category of data subject.

10.8. Rights in relation to automated decision making and profiling

Not applicable. There will be no automated decision-making or profiling.

10.9. Right to withdraw consent

Not applicable for processing by MaPS on the basis of public task.

11. Where does the data come from?

11.1. Pseudonymised user account identifiers: GOV.UK One Login (PID only) and the CDA.

11.2. Find data: Individual data subjects and the identity service.

11.3. PeIs: Pension providers, schemes and DWP.

11.4. Tokens and pseudonymised identifiers: CDA, and dashboards (requesting party token only).

11.5. Authorisations: Individual data subjects.

11.6. Complaints information: Data subjects.

11.7 Stakeholder contact details: Pension providers and schemes, connecting third parties acting for pension providers and schemes, DWP, dashboard providers, TPR, FCA.

12. Where does the processing take place?

The CDA supplier contract requires the supplier to ensure that there will be no offshoring or transmission of any data outside the UK, and that no CDA system data is processed outside the UK. The only processing of personal data that will be outside the UK is IT helpdesk (ServiceNow) data (located in Germany) and supplier project teams shared site data (processed within the EEA).

13. Authorised sub-processors

There will be no sub-processing beyond the processing by the suppliers.

14. Storage: How long personal data is retained for

14.1 Retention schedule for personal data processed in respect of dashboards users

14.2. Retention schedule for personal data processed in respect of industry personnel

Appendix A: Detailed explanation of processing of cryptographic tokens and pseudonymised identifiers

The pensions dashboards ecosystem’s technical design and consent and authorisation process at its centre relies on the use of User-Managed Access (UMA) 2.0. This gives ‘resource owners’ (individual data subjects) the ability to manage access to their ‘resources’ (pensions data) by defining an access policy at a centralised authorisation server. This involves the exchange of several pieces of personal data (UMA2 tokens) to authorise retrieval of pensions information to individual data subjects at their dashboard. In addition, there are other identifiers used to enable the pensions dashboards ecosystem to operate.

Personal data tokens and identifiers processed within the CDA

The following are the tokens, generated and/or processed within the CDA, which are classed as personally identifiable information. The processing of tokens is not linear, but tokens are ordered below as far as possible according to the sequence in which they feature throughout the dashboards process:

• Personal persistent identifier (PID): An identifier issued by the identity service in respect of an identity service verified identity (a verified identity, not a specific data subject). This is not stored but is hashed to create the Account ID.
• Account ID: A pseudonymised identifier issued by the consent and authorisation service by hashing the PID. It is stored at the consent and authorisation service and the individual’s data subject’s authorisation policies are stored under this Account ID.
• ForgeRock ID (_id): A GUID generated internally by ForgeRock to create the user as a ForgeRock object. It is included in user account token and present in the PAT and the RPT. This ID identifies the ForgeRock object on which are stored both the Account ID and the userGUID.
• UserGUID: A hash of the Account ID, issued to the dashboard when it is attempting to pull the individual data subject’s PeI(s). Used in CDA audit logs.
• Find correlation ID: A hash of the Account ID, combined with a data provider code, and issued per user per find endpoint to support pension provider and scheme and DWP identification of repeat find requests from a user to prevent repeat possible match registration once a possible match has been resolved not to be a match.
• User token: Token containing the find data, issued by the pension finder service to pension providers and schemes as a find request, for the sole purpose of matching. Not persisted at the CDA beyond the issuing of the find request. Pension providers and schemes must not persist the contents beyond the time required to process the find request and complete matching.
• User account token: A temporary token issued by the CDA alongside the user token to the pension provider or scheme to be exchanged for a PAT to register a PeI. It must not be stored beyond the time period required to process the find request and a PAT. The token contains the Account ID and userGUID.
• PeI-related UMA resource identifier: Long-term UMA resource identifier allocated by the consent and authorisation for a PeI upon registration of a PeI, used within the trusted user-managed access (UMA) API for UMA authorisation. This tells the dashboard where to send the view request.
• Requesting party token (RQP): One-time, short-lived, user-managed access 2 grant (UMA2) token issued by the dashboard and presented to the consent and authorisation service for each authorisation access by the dashboard to the consent and authorisation service. It represents the dashboard’s assertion, when requesting access, of the identity of the individual data subject in session at the dashboard, the dashboard instance, and that the user is controlling the dashboard. It asserts to the consent and authorisation service that the user controlling the dashboard instance is in session at the given dashboard.
• Persisted claims token (PCT): UMA2 token representing the association of the identity of the individual data subject at the consent and authorisation service (as verified by GOV.UK One Login) and the user and their role at the dashboard. It is issued by the consent and authorisation service to the dashboard to create a persistent association between the individual data subject’s RQP and the data subject's Account ID. Its purpose is to prevent the individual data subject from having to re-authenticate themselves via GOV.UK One Login for each authorisation (attempt to retrieve view data) at the consent and authorisation service. This makes the user journey easier for subsequent accesses if refreshing permission tokens. The PCT contains the Account ID.
• Permissions ticket (PMT): Temporary UMA2 token issued by the consent and authorisation service to the dashboard and used by the dashboard to authorise it to obtain a valid RPT. The PMT contains no user identifiers.
• Requesting party access token (RPT): UMA2 token containing details of an authorisation request, issued by the consent and authorisation service to the dashboard as a result of successful processing of a PMT. It is presented by the dashboard in authorisation requests. This includes presenting the token to the consent and authorisation service to retrieve PeIs from the CDA for an individual data subject, and presenting the token to the pension provider, scheme or DWP to enable authorisation of view requests against PeIs registered for that data subject. The RPT represents the individual data subject’s authorisation permissions for a specific PeI granted to an authenticated user after confirming authorisation to access a view pensions information. The pension provider or scheme view interface will ensure the access token is valid with the consent and authorisation service using the CDA introspect API. If the token is valid and contains permissions to the requested PeI resource, the pension provider, scheme or DWP can release the pension view details to the dashboard. Contains the ForgeRock _id.
• Protection API token (PAT): Long-lived UMA2 token representing the individual data subject’s consents and authorisations at the consent and authorisation service. That is, to control access to the data subject’s protected resources (their pensions information). It is issued by the consent and authorisation service to the pension provider, scheme or DWP and is used by the pension provider, scheme or DWP to register PeIs and to enable subsequent authorisation of view requests against PeIs. It identifies the correct Authorisation Server that protects the view data. It is hosted by the pension provider, scheme or DWP’s Resource Server on behalf of the resource owner, and authorises access to the protected resource. The PAT represents the data subject’s authorisation for the Resource Server to manage federated authorisation at the Authorisation Server. It avoids the need to disclose the user Account ID to the pension provider, scheme or DWP and to avoid tracking of the requesting party.

Use of tokens

The data subject begins at a dashboard and is redirected to the CDA (Finder service). They are redirected to GOV.UK One Login to verify their identity. Having verified their data subject’s identity, GOV.UK One Login allocates an identifier (the PID) which remains constant for the duration of the data subject’s user account with GOV.UK One Login, and issues this to the consent and authorisation service. This PID is hashed to create the data subject’s Account ID at the consent and authorisation service. Returning data subjects will be verified against this Account ID. The data subject’s authorisation policies are stored at their CDA account against their Account ID. When the PID is first issued to the consent and authorisation service, it is issued alongside the verified identity data that forms part of the find data.

Having collected verified identity attributes from GOV.UK One Login, as well as any additional self-asserted identity attributes input directly by the individual data subject, the consent and authorisation service hands off to the pension finder service to distribute the find data as a user token to pension provider, scheme and DWP find interfaces. These find interfaces receive the user token containing the find data and go about searching internal records to locate any pensions belonging to or that may belong to the data subject.

Pension providers, schemes and DWP create long-term PeIs for any found pensions and register these PeIs with the consent and authorisation service. The PeI is a URI (for example, pei:a704ecce-06c0-46ad-a399-ab9eb43568df:a3f38ece-b586-45a6-890c-9b4c045747c8), which resolves to a view URL, providing the location of the Resource Server where the pension information in respect of the individual data subject is stored.

Before the pension provider, scheme or DWP can register a PeI, they will coordinate with the consent and authorisation service to obtain a PAT. This enables the pension provider, scheme or DWP to register the PeI with the consent and authorisation service. The PAT is issued by the consent and authorisation service to the pension provider, scheme or DWP’s Resource Server. It is stored at the server alongside the data subject’s pension registration details which may include the PeI, internal keys to access the view data.

At the point of PeI registration, the consent and authorisation service allocates a UMA resource identifier in respect of the PeI. It is an index of the resource and provides long-term identification of the pension provider, scheme or DWP’s Resource Server at the consent and authorisation service. The pension provider, scheme or DWP stores this identifier to enable maintenance of the resource registration.

The dashboard then seeks to retrieve PeIs registered for the data subject in response to the find request. A PeI ID will also have been created by the consent and authorisation service by hashing the Account ID. This is issued to the dashboard when it is attempting to pull the PeIs after receiving the data subject’s find request. This is persisted and enables the consent and authorisation service to return any registered PeIs to the dashboard when the dashboard attempts to pull them. To retrieve the PeIs, the dashboard requires a valid RPT, which represents the user’s consent. The dashboard presents a PMT to the CDA, and exchanges it for a RPT. This enables the dashboard to pull the PeIs for the data subject from the CDA back to the dashboard.

The dashboard then uses the PeI to request to view their pensions information via their dashboard. This takes the form of an HTTP ‘GET’ request (call to the pension provider or scheme’s view API) using the URL which provides the location for the pension, to request access to the pension information.

To be authorised and, therefore, retrieve the pension information from the pension provider, scheme or DWP, view requests need to be accompanied by a RPT, which represents the data subject’s consent for that dashboard instance to request view data/State Pension and authorises the release of pension data by the pension provider/scheme/DWP in response to a view request, in line with the authorisation policies set by the user at the consent and authorisation service. When the dashboard attempts to make a view request, for the first view request it does so without an RPT. The pension provider, scheme or DWP UMA Resource Server uses the PAT to request a temporary PMT be issued by the consent and authorisation service to the dashboard. This temporary PMT is valid for 60 seconds. The dashboard uses the PMT to call the consent and authorisation service, to obtain a valid RPT to enable authorisation. If the RPT is valid and has permission to the PeI resource, the pension provider, scheme or DWP’s view interface retrieves the view data/State Pension information from internal systems and returns the token to the dashboard. The RPT is stored for 5 days.

The dashboard also creates and issues a single-session RQP. The RQP represents the dashboard’s assertion, at the time of each authorisation attempt, of the identity of the individual data subject, and the dashboard instance. This is then submitted to the consent and authorisation service alongside any PCT.

The PCT is a token which associates the user at their dashboard (RQP) with their verified identity as proven at the identity service (PID). The consent and authorisation service uses the PCT and the RQP to determine whether to require the individual data subject to re-verify their identity at the identity service. The PCT is persisted for 90 days and helps reduce user friction in subsequent sessions when attempting to retrieve pension details. This ensures the consent and authorisation service can identify a verified identity (the individual data subject) at their dashboards and avoids the need for the individual data subject to have to re-verify their identity each time. Initially, for the first view request, the dashboard will not have a PCT when it sends the request, so the individual data subject will be redirected to the identity service to prove their identity.