Pension Dashboard Use-Case Report

Owned by Alec Laws
Last updated: Nov 30, 2023
12 min read

Goals:

  • show UMA being used for a financial sector use-case

  • UMA implementation and applications

  • UMA value add to this solution

  • keep it under 10 pages

Audience: General/accessible. NOT TECHNICAL

 

Outline

1. Why Read This Report

In an age where data drives decisions and digital experiences shape our daily interactions, understanding the intricacies of data access, control, and protection has never been more crucial. This report is designed to offer insights and elucidate complex topics in a manner that's accessible and beneficial to a wide audience. Here's why you should consider diving into its pages:

  1. Demystify Open Banking: Open banking is not just a buzzword—it's a transformative shift in the financial world. Whether you're a seasoned banking professional or a consumer wondering how this impacts you, this report provides a holistic overview.

  2. User-Centric Approach: Understand why placing users at the forefront of authorization decisions is paramount. This report sheds light on how UMA 2.0 champions user-centricity, ensuring that data access and control remain in the hands of those it impacts the most.

  3. Stay Updated: As technological advancements shape industries, staying updated ensures you're not left behind. This report offers the latest insights into authorization frameworks and their significance in today's digital landscape.

  4. Decision Making: For professionals evaluating or deploying data access frameworks, this report offers a comprehensive comparison between traditional methods and newer approaches like UMA 2.0, aiding informed decision-making.

  5. Enhanced Awareness: Digital privacy and security are everyone's concern. By understanding the mechanisms that protect your data, you're better equipped to safeguard your digital footprint.

  6. Broad Appeal: Crafted with clarity and precision, this report appeals to readers from all backgrounds. Whether you're tech-savvy or a newcomer to the digital realm, the content is structured to be both informative and engaging.

In essence, reading this report is an investment in knowledge—one that empowers you to navigate the digital world with confidence, awareness, and discernment.

 

2. Introduction

 

In the United Kingdom, individuals have their pensions with each company they work for, and these companies usually have pension partners that manage the pension on their behalf. As individuals go through their careers and work for different companies, they acquire many separately managed pensions. The goal of this pensions dashboard program (UK PDP) is to help individuals discover and control all of their pensions across this pensions ecosystem. To achieve this the UK PDP is creating a specification and deploying technical services to help pension providers make their data available, and give UK citizens tools and dashboards to find, view and share their pensions.

The primary challenges in this system are to ensure a consistent level of consumer protection across all levels, ensure privacy and security of data, and share pension data only with the right people. Pension providers hold pension data in many different ways, and thus, a standard data and authorization model are needed. Furthermore, knowing who the user is over the internet requires access to verified online identities. In addition to these technical challenges, there are many regulations that the pension program must consider as it deals with personal financial data and different regulations apply to its different stakeholders. Consumers need notice and understanding of the privacy policy and terms of service as they interact with the different systems in the solution. Granting access to data creates new risks, and the service needs a good reputation in order for people to be willing to use it.

This report provides details of the pensions dashboard solution, its data-sharing challenges and implications, and how User Managed Access (UMA) is being put to use to overcome many of these challenges.

 

3. The Nuts and BOLTS (Business, operation, legal, technical and social) of Policy and How It Impacts the UK Pensions Dashboard Program

The UK Pensions Dashboard Program's success relies on understanding different aspects like business, operations, legal, technical, and societal matters. All of this needs to fit within the rules and laws of the UK.

For this program to work, everyone involved – pension providers, citizens, technology companies, and data users – must work together. They need to make sure the program follows UK financial and data protection rules while also creating benefits for everyone. It's important to note that pension providers can choose whether or not to participate, but the program's success depends on finding business opportunities that are good for everyone. These good business results should be achieved while following strong legal rules, especially regarding data privacy, security, and who owns the data. This follows UK rules such as the GDPR and the Data Protection Act 2018. Making sure that users agree to how their data is used is also very important.

On the technical side, we need to create a common way for all pension providers and users to share information, detailed API and authorization specifications must be in place. We must also make sure the information is accurate and secure, following the UK's data protection rules. The technology must handle the complexities of how everything works together in this distributed landscape. If the system doesn't work, people will lose trust in it. It's important that people using the system have a good experience, and this relies on everything working well together.

The success of the Pensions Dashboard Program depends on understanding all these different parts and making sure they fit within the rules and laws of the UK. The goal is to make a program that makes it easy to see your pension information, keeps your data safe, and works well for everyone.

 

 

 

4. Overview of the Pensions Dashboard solution + how it uses UMA

https://docs.google.com/presentation/d/1vmIh3lboWS_9IC4c9OHCVvxnWXoFgbpX58p6JBv2K6U/edit?usp=sharing

 

To understand how the Pensions Dashboard solution works, let’s walk though it’s basic operation through the lens of a UK Citizen.

 

Alice, a dedicated teacher in the UK, has devoted half her life to education. Now, she stands at a juncture. Over her career, she has been associated with multiple schools, each presenting her with distinct pension plans. These plans differ in terms of rates, benefits, and conditions. While she's adept at educating numerous students, navigating the maze of her varied pension schemes is a challenge she seeks assistance with.

Enter Bob, a renowned independent financial advisor, with a track record of guiding over a thousand clients toward their financial aspirations.

Traditionally, Alice would gather documents from each pension plan, and Bob would sift through the information, offering tailored advice. However, the Pension Dashboard Programme streamlines this process. Bob simply prompts Alice to log into the portal, where the dashboard amalgamates data from all her pension schemes, presenting a consolidated view.

 

[new diagram 1 ]

 

(rough) Alice is able to login with an existing verified identity, she’s then prompted to consent to find her pensions automatically. She is then returned back tot he dashboard and can see all her pension information from her many years of teaching. On the dashboard, Alice has a simple way to grant Bob access, and is presented a link to share with Bob.

 

[ new diagram 2]

Bob is able to enter the link in his advisor specific software and login with his professional financial advisor credential. He then automatically able to see all of Alice’s pensions

 

 

This scenario underscores several key requirements:

  1. User-Centric Consent Management: Alice retains the autonomy to share her pension details with the Pension Dashboard Programme and can withdraw her consent whenever she wishes.

  2. Delegation and Proxies: With Alice's approval, Bob can access and review her pension details, acting as her delegate.

  3. Distributed Infomation Policy Enforcement: Consistency is maintained in access policies across all pension providers. Pension Data doesn’t not need to be centralized, instead it stays with the pension provider systems and is accessed directly by dashboard or advisor software

 

 

5. Why UMA was the right choice

OAuth 2.0 stands as a widely implemented authorization protocol, particularly known for its client-centric approach. Applications, acting as clients, are often entrusted to request resource access on behalf of users. This method, while practical in many scenarios, has revealed several limitations impacting user control and data access transparency.

Client-Centric Authorization Challenges

The OAuth 2.0 protocol's emphasis on client initiation for authorization requests frequently results in reduced autonomy for users. In this structure, the decision power is shifted away from the user, who is typically only presented with the binary choice to grant or deny access without the capability to fine-tune the permissions. Although this system informs users of who is requesting their data, thereby promoting transparency, it simultaneously curtails their control over their financial data's management.

Scope Definition Concerns

In OAuth 2.0, the level of access a client requests is defined by scopes. These scopes, however, tend to be broad and may not accurately reflect the specific data elements or actions that a user is comfortable sharing. This broadness often stems from clients creating scopes, leading to a mismatch between user intentions and the permissions granted. Differing scope definitions across various OAuth 2.0 services add another layer of complexity and inconsistency.

Consent Prompt Limitations

OAuth 2.0's consent prompts are designed to offer users a degree of control over their data. Nevertheless, this control is typically limited to accepting or rejecting predefined scopes, which may not align with the user's detailed preferences for data sharing and access.

Dynamic Authorization and Delegation

Unlike UMA 2.0, OAuth 2.0 does not inherently support dynamic, user-driven authorization. It provides no mechanism for users to modify permissions post-authorization without re-engaging the client. This limitation is in stark contrast to UMA 2.0, which facilitates dynamic authorization, allowing users to adjust access policies autonomously.

The Passive Role of the Resource Owner

Within the OAuth 2.0 framework, users are labeled as "resource owners," yet their role is substantially more passive compared to user-centric models like UMA. Users are often relegated to the role of gatekeepers who can either approve or block access, without the facility to actively manage their resources.

Consent Persistence and User Control

OAuth 2.0 typically maintains consent through long-lived access tokens, which could restrict the user's ability to revoke access as their preferences evolve. On the contrary, UMA 2.0 enables users to define expiration parameters directly through the UMA Authorization UI, offering a more flexible and user-driven model of consent management.

 

In conclusion, these identified limitations of OAuth 2.0 highlight the need for a more nuanced, user-centric approach to authorization, particularly in handling sensitive information such as financial data. UMA 2.0's framework addresses these concerns, providing users with a higher degree of control, transparency, and flexibility, thereby making it a more suitable choice in scenarios demanding stringent data protection and user empowerment.

5.2 OIDC vs UMA

User-Managed Access (UMA) 2.0 and OpenID Connect (OIDC) serve complementary roles within the realm of secure data access, particularly in the burgeoning sector of open banking.

OIDC plays a crucial part by focusing on the authentication aspect. It is responsible for confirming the identity of the user, ensuring that the individual trying to gain access is indeed who they claim to be. This authentication mechanism is pivotal, especially in financial contexts, as it acts as the primary gatekeeper, preventing unauthorized entities from initiating any kind of transaction or access.

On the other hand, UMA 2.0 delves into the intricacies of authorization and fine-grained access control. Once a user's identity is authenticated through OIDC, UMA 2.0 takes the reins to determine what specific resources or data points the user, or any delegated entities, are permitted to access or modify. This is particularly valuable in scenarios where a user might wish to grant limited access to specific parts of their financial data to third-party apps or advisors.

Together, OIDC and UMA 2.0 present a dual-layered security approach for open banking applications. The seamless integration of identity validation through OIDC with the nuanced authorization capabilities of UMA 2.0 ensures that user data remains both accessible to authorized parties and safeguarded from potential breaches. This union not only enhances security but also empowers users, granting them greater control and transparency over their financial data.

6. Conclusion

"Open banking" represents a paradigm shift in the financial industry, where traditional banks and financial institutions open their doors—virtually—to third-party developers through application programming interfaces (APIs). This innovation empowers these developers to craft cutting-edge financial products and services that seamlessly integrate with the established systems of banking institutions. However, this promising vision of financial innovation hinges on one fundamental principle: the unwavering trust and explicit consent of the account holder.

Yet, traditional models, like OAuth 2.0, though robust in many respects, have shown limitations in ensuring the degree of control and transparency that today's users demand, especially when it comes to the intricate and sensitive nature of their financial data.

Enter UMA 2.0—a framework that emerged as a beacon of user-centricity in the realm of data authorization. Unlike its predecessors, UMA 2.0 is meticulously crafted to offer users an unparalleled level of control over their data. With its capabilities for fine-grained access policies, the dynamism in authorization, and an intuitive consent management system, UMA 2.0 stands out as an ideal choice for any scenario that requires a heightened emphasis on user-centric control, transparency, and data protection. This becomes particularly pertinent in scenarios involving sensitive information, such as pension data, where the stakes of unauthorized access are incredibly high.

In conclusion, as the financial landscape evolves with the onset of open banking, it is imperative that the tools and frameworks we employ evolve in tandem to prioritize user trust and data security. UMA 2.0, with its user-centric ethos, provides a promising path forward, ensuring that as we innovate, we never compromise on the sanctity and security of user data.

Appendix

Appendix A: Kantara + pensions dashboards programme relationship (About This Report and the Standards Mentioned)

Appendix B: References/ Bibliography

Appendix C+: as needed if we want to get into tech/other details

Alice's Pension Consolidation Using UMA 2.0 Framework

 

 

  1. Initial Point of Contact: Bob shares a link with Alice, directing her to his company's Pension Dashboard where she can view all her available pensions.

    UMA 2.0 Insight: For delegation within UMA 2.0, the resource owner (Alice) must designate a proxy within the UMA system, indicating details like identity, capabilities, and resource scopes. In our scenario, the Pension Dashboard is a proxy registered with defined scopes of authority.

  2. Authorization Process:

    2.1. Alice accesses the dashboard and is redirected to the Pension Programme's Authorization Server to retrieve her pension details.

    2.2. At the Authorization Server, Alice logs in using a pre-existing Identity Provider. Federation of Alice's identity with her pensions necessitates her having an account with the Authorization Server.

    2.3. As a first-time user of the Pensions Dashboard system, Alice grants permission to the Pension Finder service to locate her pensions.

    UMA Insight: Even though the Identity Provider isn't a core UMA component, user authentication is vital and facilitates the discovery of her distributed pension data.

  3. Pension Discovery Process:

    3.1. The Pension Finder service, not directly UMA-compliant, initiates search requests to all registered pension providers using Alice's details. All providers must acknowledge these requests, returning only an HTTP status 202.

    3.2. Responding to these requests, pension providers register the inquired resources as UMA resources in a backchannel communication process. In exchange, the Authorization Server issues a unique identifier (PEI) for the resource and its scopes, enabling dashboards to make parameter queries.

    UMA Insight: This PEI functions similarly to a UMA capability ticket.

  4. Access and Delegation of Pensions:

    4.1. Alice views her discovered pensions at the authorization service and grants Bob, her financial advisor, delegated access rights to view her pensions with Employers A, B, and C.

    4.2. To enable Bob to view Alice's pension data, Alice must establish this delegation rule within the Authorization Server.

    4.3. Alice also permits the Pension Dashboard's view request, returning to the dashboard for a comprehensive look at her pensions with Employers A, B, and C. The dashboard retrieves the PEI (UMA capability) from the Authorization Server and initiates the UMA process to procure the RPT and retrieve the pension information.

  5. Sharing with Financial Advisor: Alice shares her pension identifiers with Bob, granting him direct access to view them.

Bob's Access to Alice's Pension Information via the Authorization Server (AS)

2.1 Initial Login at AS: Bob signs in to the Authorization Server using his credentials as a regulated financial advisor to ensure secure access to the Pension Dashboard.

Note: Authenticating oneself is a prerequisite for any user, including financial advisors like Bob, when accessing the Pension Dashboard.

2.2 Requesting Access: Utilizing the pension identifiers shared by Alice, Bob attempts to access Alice's pension data associated with Employers A, B, and C.

2.3 Delegated Access Process: Bob's dashboard employs these identifiers, subsequently redirecting Bob to the Authorization Service for further authentication.

Context: Earlier, Alice registered her pension plans as UMA resources and granted consent within the Authorization Server. She also permitted Bob to access her pension data. Consequently, the Authorization Server created a unique identifier (PEI) for this process. After obtaining the PEI, Bob's dashboard can request the Authorization Server to fetch the UMA resource listed on it.

2.4 Authorization and Data Retrieval: The Authorization Server, upon introspecting the incoming PEI and verifying the consents, identifies the valid consent Alice provided for Bob. It then sends the relevant pension data to the dashboard.

Insight: This step ensures that only those with proper delegated access can view the sensitive pension data.

2.5 Data Visualization: Consequently, on his dashboard, Bob successfully views Alice's consolidated pension information, enabling him to assist her with financial advisory services.