Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 28 Next »

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

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 pensions 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.

 Notes

to use case and data-sharing challenges/implications that need to be addressed [next step: bullet points to paragraphs]

  • [context]

    • individuals have a pension managed by each company they work for, and companies have pension partners that manage it for them

    • user personas: UK citizens and financial advisors

    • industry stakeholders: companies that have employed people, pension scheme providers, UK Government (MAPS), technology vendors/partners

  • [Goal] Put user’s interest first. Ensure individual data is secure, accurate and simple to understand and available to them. Ensure that individual is always in control over who has access to their data

  • [Challenege - maybe omit the “how it’s solved part from the intro, leave for later sections”]:

    • Consistent level of consumer protection across all level. privacy and security of the data, only sharing pensions data with the right people

    • On board the majority of pension providers who are holding pension data is many different ways → need a standard data (pension data model/schema) and authorization model (uma)

    • knowing who the user is over the internet → federation to CSPs and UMAs ability to work with many IDPs

    • pension data is held by each previous employers, a citizen may have many pensions across UK organization → find function + uma ability to protect many RSs

    • there are many regulations the service must consider, as the data is accessed (by dashboards?) different regulations apply to it → consumers need notice and understanding of the PP/TOS

    • granting access to data creates new risks, the challenge is establishing trust in the service. Service needs a good reputation in order for people to be willing to use it

  • UMA is being used to address 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 successful implementation of the UK Pensions Dashboard Program relies on a comprehensive understanding of its various dimensions, encompassing not only the technical aspects but also the broader business, operational, legal, and social implications. This section delves into the intricate interplay between these components and how they collectively shape the policy framework of the Pensions Dashboard Program.

Business Implications

The business landscape surrounding the Pensions Dashboard Program is multifaceted, involving stakeholders from pension providers, financial institutions, technology companies, and government bodies. A key challenge lies in fostering collaboration among these diverse entities to ensure data accuracy, accessibility, and security. Business models will need to adapt to accommodate new revenue streams and service offerings, while competition and innovation are expected to drive enhancements in user experience and value-added services.

Operational Considerations

Operationalizing the Pensions Dashboard Program involves intricate logistics, ranging from data collection and integration to maintaining a responsive user interface. The operational architecture must be robust enough to handle vast amounts of data from a myriad of sources while maintaining real-time updates. The potential for operational bottlenecks and service outages necessitates rigorous stress testing and contingency planning to ensure smooth day-to-day functionality.

Legal Framework

The legal dimensions of the Pensions Dashboard Program revolve around data privacy, security, and ownership. Striking a balance between facilitating seamless data sharing and protecting individuals' sensitive financial information requires a robust legal framework. Data protection regulations, such as the General Data Protection Regulation (GDPR), must be carefully considered, alongside the development of user consent mechanisms that empower individuals to control their data while participating in the program.

Technical Underpinnings

At the core of the Pensions Dashboard Program lies its technical infrastructure. Developing a standardized data schema and API framework is crucial to enable interoperability across various pension providers' systems. Ensuring data accuracy, integrity, and security is paramount to build user trust. Scalability, as the program gains popularity and the number of users increases, is a technical challenge that demands foresight and robust engineering.

Social Dynamics

The social impact of the Pensions Dashboard Program extends beyond its operational and technical facets. Increased financial transparency can empower individuals with a clearer understanding of their retirement planning, leading to improved financial literacy and informed decision-making. Simultaneously, the program must address potential concerns surrounding data breaches and unauthorized access, cultivating a sense of trust among users and society at large.

The Pensions Dashboard Program's successful implementation hinges on a comprehensive understanding of the diverse dimensions it encompasses. The business, operational, legal, technical, and social components collectively shape the policy framework that drives the program. By addressing the intricate interplay between these dimensions, stakeholders can collaboratively build a program that not only enhances financial inclusivity and transparency but also safeguards user data and fosters a secure and robust digital ecosystem for pension management.

 Notes

Paragraph

The term "policy" covers many different elements, including business, operational, legal, technical, and societal aspects. The identity industry has taken to calling this "BOLTS". These policy systems typically address liability, access control, compliance, patient transparency, and more. Touching on a few key examples:

● There is a robust regulatory landscape that defines how health systems must operate, for example, touching on security, privacy, covered entities, consumer protection, the Internet of medical things, and more. ● At the societal level, issues of public health, consent, anonymization, and clinical research arise.

● Businesses with different financial models and regimes come with a variety of oversight mechanisms and associated policy.

● Health data ecosystems often manage data sharing through bidirectional contracts or through “trust frameworks” that function as master service agreements.

– need to look into the UK landscape and what BOLTS are relevant here [ next steps: keep looking at references and weave into a bit of story ]

  • can also re-purpose content from the Julie use-case as a template for this section

There’s a lot of regulation/policy that a pension provider has to meet at the same time, for example… DPA + pension act and now the new pensions dashboard regulation

  • Let’s take inspiration from this section in the Julie Use-case Report

  • overview of regulations/acts/policies that apply to different stakeholders

  • briefly state what they mean or the main obligations

  • privacy regulation: sharing or PI during find, the finding of advisors

    • UK not part of GDPR, the UK has it’s own Data Protection Act created/updated(?) 2018

  • Dashboard may offer delegated access only to defined user group

    • MaPS advisors

      • A person with permission to advise on investments as referred to article 52(1) of FSMA 2000 (regulated activities) order 2001 (a) who can provide further pension advice and guidance to individual

      • A person with permission to advise on conversion or transfer of pension benefits as referred to artcle 53E of FSMA 2000

  • references that may have more specific information about regulations

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

  • diagram

  • pension provider registration, dashboard registration, user and advisor identity

  • find pensions (not uma), pension registration (uma fedz), pension management + delegation (@the uma as), pension viewing (Uma grant)

  • not happy paths

  • someone who understands the pension dashboard use-case and flows could read this section and gain an understanding on UMA

To make the pensions dashboard program work, a number of parties and technical components must work together to build an ecosystem. (https://www.pensionsdashboardsprogramme.org.uk/ecosystem/ )

Actors:

  • UK Citizen (UMA RO + RqP)

  • Financial Advisors (UMA RqP)

Technical Parties + Systems

  1. Dashboards are the main service UK Citizens are being enabled to use. The dashboard receives authorization to access a UK Citizens' pensions and allows the person to see a consolidated view of all their pensions across the ecosystem. The Dashboard is an UMA Client

  2. Pension providers (UMA RS)

  3. Consent and authorisation service - the UMA AS. The hub for the pensions dashboard ecosystem

  4. Pension finder service - not UMA role, customer to UK Pensions Dasboard Arch, however they facilitate resource registration from providers to the AS

  5. Identity Service - Traditional IDP

  6. Governance Registry - not an UMA Role, often the UMA AS

UK citizen Alice is assigned with a financial planner Bob. She is seeking professional advice from Bob so that Alice can fully utilize her pension.

The User Flow with UMA

Alice is one of diligent teachers in UK who spent half of her life in education. And now she finds herself at a crossroad. Because during her career, she worked at multiple schools, and each school offered her different pension plans. Those pension plan varies from rate, terms, benefits. Despite she has taught many students, this time she needs some help to unravel the complexity of different pension plans and maximize her finances.

Bob is a well known independent financial advisor who has helped 1000+ clients set their financial goals.

The straightforward use case is that Alice brings required document of different pension plans and Bob will collect necessary data and give advice accordingly. However, with pension dashboard programme, Bob can asks Alice to login the portal and the dashboard will consolidate all of her pension plans data in one place.

In this case, there are serveral demands arising:

  • User centric consent management

    • Alice can choose to share her pension plan with pension dashboard programme and cancel at any time

  • Delegation and proxies

    • Once Alice gives her consent, Bob can view Alice’s pension plans on behalf of Alice

  • Policy enforcement

    • The access policy is consistent among all pension plan providers

To illustrate how UMA 2.0 address those concerns, let’s dive into details

0 Alice’s pensions are held by several previous employers across the UK: Employer A, B and C

In UMA 2.0 framework, resource owner’s resources are held by many resource servers at various locations (eg. urls). And these resources & clients must be registered at Authorization Server with scopes, which helps users manage their resources and increases the granularity of access control.

Back to pension dashboard programme, Alice’s phone is the user agent, the pension dashboard is the proxy, Bob is the third party delegates to Alice. Prior to the delivery phase, all of the popular pension providers & dashboards are required to register in Authorization Server, and they must provide the data type defined by the Authorization Server. So far, the first step of pension plan consilidation is done.

1.1 Bob gives Alice a link to his companies pension dashboard where she’ll be able to view all her available pensions

To enable delegation in UMA 2.0, resource owner must define the proxy in UMA system. And it should provide information such as identity, capability and scopes of resources.

The pension dashboard in this case is a registered proxy with fine grained scope of authority

1.2 Alice visits the dashboard and is sent to the pension program Authorization Server to gain access to Alice’s pension information

The authorization server helds all resources

1.3 At the authorization server, Alice log’s in with an existing Identity provider

In order to federate Alice’s identity and pensions, Alice has to create an account in Authorization Server.

1.4 Since it’s her first time using the pensions dashboard ecosystem, she provides her consent for the Pension Finder service to discover her pensions

Although identity provider is not a UMA component, the end user must be authentcated.

1.5 The pension finder services query all the registered pension providers with Alice’s information

Pension finder service isn’t UMA conformant, it is component that actively push search request to pension providers. All the pension provider have to respond to the search request. Please note that the search request will not return any information other than http status 202.

1.6 Employers A, B, and C are able to find pensions for Alice and register them as UMA resources with the Authorization Server

While handling the search request, pension provider will register the requested resource as UMA resource in the back channel. And in return, the authorization server will generate an unique identifier (PEI) for the requested resource and scopes. The PEI is used by dashboard to query parameters.

The PEI can be think as a UMA capability ticekt.

1.7 Alice can now see her pensions and is able to look up her financial advisor Bob and grants him delegated access to view her pension at Employer A, B and C

The authorization server manages all the delegated & user owned resource relationships. To make Bob see Alice’s resources, Alice has to setup this rule in the Authorizaton Server.

1.8 Alice also authorizes the view request of the pension dashboard and is sent back to the dashboard

1.9 At the dashboard, Alice is able to view all her pension information from Employer A, B and C

Once the dashboard knows the user’s account at the authorization server, it can pull the PEI (UMA capability) from authorization server. And it will trigger the UMA flow to obtain the RPT.

1.10 Alice shares the Pension identifiers with Bob so he can view them himself.

2.1 Bob logins to the AS using his credentials. ?

In order to access Pension Dashboard, Bob has to identify himself.

2.2 Bob tries to access Alice’s pension information using the shared pension identifiers at Employer A B and C

2.3 Bob’s dashboard follows the identifiers and Bob is then redirected to the Authorization Service to authenticate himself.

In the previous step, Alice has registered her pension plan as UMA resources and given consent in Authorization Server, and agreed to let Bob delegate her to access pension plans. As a result, the authorization server generates an unique identifier (PEI) for the above process. Once Bob’s dashboard obtained the PEI, it can ask the authorization server to retrieve the UMA resource registered on it.

2.4 The Authorization Server sees that Alice has granted Bob delegated Access to those pensions and returns Bob to the dashboard

The authorization introspects incoing PEI and search through all the consents. Upon finding the valid consent, it will sends pension data to Dashboard.

2.5 At the dashboard, Bob is able to see Alice’s pension information

In the end, Bob will see Alice’s data in his dashboard.

  • high-level description of main flows

    • Pre-requsite

      • Registration: Registration of OAuth client is required for operation of UMA profiles. The governance register (which includes the UMA authorization server as the software entity managing software client registration) will provide services for client registration.

      • Our AS is expecting to support dynamic client registration & provision in the future

      • Pension provider scheme (UMA resource Server) must comply the UMA FedAuthz protocol, which means that a valid PAT must be acquired before calling token introspection, permission and register API.

    • login + consent + find (UMA Resource Registration)

      • Dashboard initiates authorization requests, and provide a set of claims. In return, the Authorization Server will issue a RPT for the dashboard to authorize its view request.

      • Upon a successful match, the pension provider will need to use PAT to register Pei with Authorization Server. This means that we’re putting the matching user (resource owner)'s resource under UMA protection.

      • The pension provider (Resource Server) should persist these items in a way that allows it to locate them using inbound URL of view request

      • Pension provider respond with 202 Accepted Http Status (implying acknowledgement of find request)

    • delegate (UMA delegation @ AS)

      • The advisors that are using Pension Dashboard will send view request to pension provider.

      • And the pension provider is capable of accepting and responding the requests to protected resource on behalf of resource owner.

    • view (UMA Grant flow) Either by the Citizen or their delegated advisor

      • Dashboard send a view request with PeI to Pension provider

      • If view request made by dashboard has a rpt

        • Subsequently pension providers uses PAT to perform token introspection

        • AS will introspect the relationship and return permission to pension provider

        • Pension provider dereference the Pei and return the pension detail

      • If view request made by dashboard doesn’t have a rpt / have invalid rpt

        • Pension provider (RS) will send permission request to Authorization Server and request permission. In return, RS will get UMA permissions (defined in UMA Grant and UMAFedAuthz using scope defined in profile).

        • Then Dashboard will use the permission ticket to initiate UMA grant protocol with AS to obtain a new RPT

EcoSystem Diagram

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

5. Why UMA was the right choice

  • multiple RSs, federated RSs, delegation/RqP/resource-sharing, self-management of access policy, clients stay unaware of authorization/policy

  • it’s not OIDC or identity federation, it’s data access

  • without getting too technically deep!

6. Conclusion,

extension to openbanking + other use cases, comparison to other places

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

  • No labels