Pensions Dashboard 900X330px

EQ Responds To The Pensions Dashboards Programme Call For Input On Identity

22 April 2021

By Chris Connelly, Propositions and Solutions Director

Chris Connelly

 

We sat down with Chris Connelly, Propositions and Solutions Director, to talk us through the recent developments of the Pensions Dashboards Programme.

Chris also discusses EQ’s recent response to the Money and Pension Service's (MaPS) call for input on identity, which looks at the proposed methods to verify that dashboard users really are who they say they are.  

Often, in our industry, we never meet the people we serve. Their employer usually tells us who has joined. They themselves have checked the employee’s identity, and we as scheme managers or trustees trust that they have done so. Have we ever checked how rigorous the recruitment process was to prove someone is who they say they are?

Wind forward 20, 30 years when our member has long since left that company, moved house three times, got married, divorced and re-partnered. We have to re-identify them to make sure we are paying the right person the right amount at the right time.

We probably all have our own well-honed processes. Some will still be paper-based, but increasingly they will be digital and biometric. Whatever we all do will rely on something they have to prove who they are (for example, a certificate) and something they know, such as a pin, password or old address.

In the future, there will be a new front door for members that gives access to the personal and benefit data we control and process: Pensions Dashboards. The member will control how secure that front door is going to be. Not you.

The GDPR conundrum

GDPR

How do you solve the problem of a data controller needing to satisfy a member’s GDPR rights, and share that data in a place of their choosing? And that place of their choosing is not your website? And that member may not have ever spoken to you or met you before. How do we create a circle of trust around these three separate entities?

Pensions Dashboards will enable members to make online requests to find all their UK pensions (not yet in payment), so they can securely view all their pensions in one place, i.e. on their chosen dashboard.

Pensions Dashboards will achieve this very powerful service via a central digital architecture, explained in this 2-minute video, published by the Pensions Dashboards Programme (PDP). 

As explained in the video, the digital architecture is going to include a central Identity Service (IDS), which will confirm that the person logging into their chosen pensions dashboard is actually who they claim to be.

Looking to the industry

Last month, the PDP published an outline of how they propose the service will work and asked for our industry’s views. The PDP is proposing to require identity service provider(s) to prove, and then authenticate, dashboard users’ identities in line with two existing Government good practice guides:

GPG45 is for checking identity for the first time and creating a new digital ID. GPG44 covers returning visits. Both guides have levels of assurance in them: how confident are you that the evidence you have seen proves this identity? There’s a scoring mechanism which I will spare you the details of, but at the highest level, identity is measured by scoring evidence from five different perspectives:

Strength: How strong is the evidence provided of the claimed identity?
Validity: How valid / genuine is the evidence of the claimed identity?
Activity history: How extensive is the evidence that the claimed identity has existed over time?
Identity fraud: Is there evidence that the claimed identity is at high risk of identity fraud?
Verification: How strong is the evidence that the identity belongs to the person who is claiming it?

If the evidence scores well against these five perspectives, this provides confidence that the individual is who they say they are.

My major criticism is that one of the guide’s weaknesses is the choice of names they give these levels of assurance, which can be a barrier to understanding.

What’s in a name

Pensions Whats In A Name

The level of confidence being proposed for Pensions Dashboards is called “Medium”. That doesn’t sound too convincing and will probably lead to a lot of responses from people who perhaps do not know the details to say, “Why not High?”

In fact, “Medium” is quite, er… well… high. See what I mean about naming conventions? It may well even be higher than you already insist on. For example, if your online member self-service only asks for a username and password, then “Medium” is higher. GPG44 Medium introduces multi-factor authentication. 

For example, having to use a second way of confirming who you are. A common tool today is receiving an email or a text to a device you have previously used so that you can confirm it is really you logging into the website.

For identifying someone for the first time (GPG45), a “Medium” level of confidence indicates that there is very strong, genuine/valid and real-world evidence that the individual’s claimed identity exists.  It also reduces any known risks of fraud of the identity and gives confidence that the individual using the dashboard matches their evidence of identity. It is also fair to say that it is not an iron-clad guarantee.

The Government decided “Medium” was appropriate for citizens signing up to use the online State Pension checking tool and has extended that logic to Pensions Dashboards.

As stated in the response below, EQ agrees in principle that Medium is probably a fair reflection of the balance of risks, for now. Security is always a balance, and the balance continually shifts. Too little or too easy, and members would be unsure and uncomfortable using it. Too much or too hard, and you risk members not getting over the hurdles and not using the service. That would mean the initiative fails its objectives. You need to find a middle ground. Security professionals sometimes refer to security as “appropriate friction” rather than “frictionless” because people gain comfort from an appropriate challenge.

Over time, as digital IDs become more prevalent and more user-friendly, we would expect to see the security levels rise. Initially, Pensions Dashboards will be information-only services, so Medium seems appropriate. However, in future, the roadmap for online dashboards and tools will lead to transactions becoming possible. At that stage, we would expect the bar to rise to High.

You can read the full EQ response below. As you will see, EQ is posing a number of questions back to the programme to ensure their plans for Identity and Security will satisfy your needs.

Please take a look, think about how you identify people today and let me know what you think.

Do you agree that finding pensions and viewing pension details via a pensions dashboard should include a central digital identity, asserted to an appropriate standard, in accordance with the GPG 45? If no, what alternative approach would you recommend?

We agree that a central digital identity with a known and understood assurance level is essential to data controllers being able to agree to their data being shared outside of their own systems.

We believe there is scope for there being multiple verifiers of identity to avoid bandwidth issues or single points of attack and to encourage improving capabilities, but that must come with a common standard so that they are interchangeable seamlessly to the user.

At the same time, that standard will give comfort to the Data Controllers that no matter who did the identity checking and verification, it has been done to be at least a minimum level of assurance.

The proposal includes a level of confidence in identity and a level of authentication. Do you have a view on the level of assurance that needs to be achieved to provide comfort to release pension information? If Yes, what elements do you think are the primary factors? If No, what additional information would you need to be able to make an assessment?

We agree that security is a balance of risks. Primary concern must be that data is not breached and exposed to the wrong subject. However there is a practical concern too that something could be “too secure” and become unused and miss the point of providing this service.

It would be interesting to know what conclusions led the State Pension team to agree that “Medium” was the appropriate level of assurance to access state benefits. It would be equally interesting to know what level of process drop outs it gets when citizens do not complete the identity journey.

If it is felt that the balance of risks has been managed there, then we do not see why using this level of assurance should be any different for the rest of the pensions sector.

In the interests of future proofing however, you should set the expectation now that any future increase in functionality to support financial transactions such as aggregation journeys would require an increase in level to “High”.

The suggested levels of confidence (GPG 45) and authentication (GPG 44) are ‘medium’, which equates to the previous versions of the standard level of assurance two. Do you agree that this is the correct level? If No, what would you suggest is the correct assurance level for both proofing of identity and strength of authentication?

Yes, but see our comments in the previous question.

We believe the challenge will be explaining this to Trustees and Employers (the data controllers) and what this really means in practice. Early feedback from our own clients and amongst our peers in PASA was that the instinctive reaction to the word “medium” is “why not high?” Many who instinctively react that way will not realise that their current practices with member self-service are probably historically below the level assured by “medium” practices.

Of course, in workplace pensions, data is inherited from the employer. The people responsible for the data in a pension scheme were not those responsible for identifying the members in the first place. However, they are the ones that invite those members to engage online and so they will be more familiar with the practices that GPG44 is related to: the ongoing authentication of ‘repeat’ users. i.e. pre-validated people returning to use the service subsequently. Increasingly clients are expecting multi-factor authentication in these scenarios and so, probably without knowing it, are aligned to GPG 44 Medium.

Whilst this is not the question you asked us, it does give rise to more questions of our own. We believe this information will also be required by Data Controllers so that they fully understand MaPS’ proposals here:

    1. Who will be the data controller of the dashboard and the special personal data collected?
    2. Where and with whom will individuals exercise their rights?
    3. In addition, this is likely to result in automated decision making and profiling – who will be responsible for the DPIA and related security controls?
    4. We would need to understand spans of controls and who owns which liabilities at specific points of the data flow map.
    5. The identity checks performed to provide a medium level of assurance are not guarantees. As Data Processors who aren’t in charge of the security aspects, we would also want to know (alongside the Data Controllers) who would be responsible if a data breach occurred as a direct result of a dashboard data exchange where the identity had passed the central security check?

Is there an alternative to the default levels of assurance from the Good Practice Guidelines and how would you anticipate them being measured?

We do not believe so. Where we directly get involved in ID&V or KYC activities on behalf of our customers we use services that already follow practices similar to those articulated in the GPGs.

Does your firm have any view on proofing or authentication methods and operate a current internal standard that differs from the GPGs medium level? If Yes, could you please provide an overview that could help direct the programme’s approach?

Historically, we have allowed our software clients to choose whether they deploy MFA or not in our member self-service offerings. Increasingly it is likely that this will no longer be optional. So the direct answer is that some current practices are lower than medium, but would expect that to drift upwards as understanding increases.

The architecture includes the central identity service to ensure that a uniform, controlled process exists, and that a user can easily manage their own consents. Please provide your thoughts on this approach and any challenges that you may foresee.

A central and consistent approach would be essential. Not just for the user experience and seamless interchangeability of underlying ID provider. It will also support the principle of data minimisation with the dashboard as otherwise multiple pieces of information would need to be collected to meet multiple frameworks – a single and consistent approach should therefore achieve the objective of data minimisation.

Are there any specific requirements that you would anticipate the Pensions Dashboards Programme having to meet when seeking (a) your firm’s approval for a standard approach to identity assurance (b) a cross industry agreement on a standard for identity assurance Identity approach?

It is interesting you use the phrase “your firm’s approval”. We understand this is aimed at the firm being the Data Controller, but as Data Processors breaches would fall on us too. In what scenarios do you envisage that a firm (Data Controller) could refuse to give their approval?

Whilst data subjects have the right under GDPR to have their data transferred to the place of their choice, the data controller has responsibilities to check and may refuse if it is deemed unsafe. If the secondary dashboard legislation compels Data Controllers to provide data to dashboards, but the controller in question does not consider GPG 44/5 Medium safe enough and so refuses, where does that lead us? Which legislation wins out? Compulsion or GDPR?

We highlighted a number of questions earlier in our responses that we would also want to understand better. In addition could the State Pensions team or ICO be able to share insight on the volume of data breaches reported where the State Pension has deployed a Medium level of assurance.

Lastly we also believe that as everyone needs to understand how the front door to their data is being controlled by an entity that they do not directly control, there should be continued engagement during the Data Protection Impact Assessment process and publication of the results would also aid demonstration of compliance with DP regulations. We understand the Education Department recently shared their DPIA findings when switching under COVID-19 restrictions from examinations to teacher assessments. Perhaps the same transparency can be shared here too.

What security related controls (other than identity proofing and authentication) do you see as important in your acceptance of the PDP solution for Pensions Dashboards?

As mentioned before, we would like to see the DP impact assessments of all of the infrastructure, and understand the spans of controls and who owns which liabilities at specific points of the data flow map.

Additionally, whilst not related to the identification and verification, this process falls down if the underlying data processors and controllers are unable to successfully match the request to an internal record. To this end we believe the degree of assertion to each data item needs revisiting. We would push back on the proposal that the NI Number is only asserted by the end user and not checked at any point as part of the verification. NI Numbers are a vital part of the data that data processors will use to match.

If you would like to talk about your preparations for the pensions dashboard, please contact us below.



We have detected that you are in United States. We think that Equiniti US would be more suited to deal with your needs.