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 36 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

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.

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

 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

 Key point

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 Resource Server)

  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

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.

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. Policy Enforcement: Consistency is maintained in access policies across all pension providers.

To elucidate how UMA 2.0 addresses these nuances, let's delve deeper.

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.

 old content

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 [view step] 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.

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.

 Old content

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.

Overall Flows in the Pension Dashboard Using UMA

Prerequisites:

  • Client Registration: Essential for the operation of UMA profiles. Our Governance Register, incorporating the UMA Authorization Server responsible for software client registration, will facilitate this process.

  • Future AS Capabilities: Our Authorization Server (AS) is projected to support dynamic client registration and provisioning in the forthcoming phases.

  • UMA Protocol Compliance: Pension provider schemes (acting as the UMA Resource Server) must adhere to the UMA FedAuthz protocol. A valid PAT (Protection API Token) is mandatory before invoking token introspection, permission, and the register API.

Login, Consent, and Resource Registration:

  • Authorization Initiation: The Dashboard commences authorization requests, submitting a set of claims. The AS responds by issuing an RPT (Requesting Party Token) to authorize the Dashboard's view request.

  • UMA Protection: Upon a successful match, pension providers use the PAT to register PEI (Pension Entity Identifier) with the Authorization Server, thereby safeguarding the matching user's resources under UMA.

  • Data Persistence: Pension providers must store data in a manner that enables easy location via the inbound URL of the view request.

  • Acknowledgement: Pension providers acknowledge find requests with an HTTP status of 202 Accepted.

Delegation at AS:

  • Advisor's Role: Advisors utilizing the Pension Dashboard forward view requests to pension providers.

  • Request Management: Pension providers possess the capability to accept and manage requests for protected resources on behalf of the resource owner.

Viewing Process (UMA Grant Flow):

This can be initiated either by the citizen or their delegated advisor.

  1. Dashboard Interaction: The Dashboard sends a view request along with the PEI to pension providers.

  2. Valid RPT Presence: If the view request from the dashboard contains an RPT:

    • Pension providers utilize the PAT for token introspection.

    • The AS examines the relationship, returning permission to the pension provider.

    • Pension providers retrieve the PEI, providing pension details in response.

  3. Absence or Invalidity of RPT: If the dashboard's view request lacks an RPT or contains an invalid one:

    • The pension provider forwards a permission request to the AS, subsequently obtaining UMA permissions (defined in UMA Grant and UMAFedAuthz using scopes defined in the profile).

    • The Dashboard then uses the permission ticket to activate the UMA grant protocol with the AS, aiming to procure a new RPT.

 Old content

  • 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

 Old content

  • 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!

Why OAuth / OIDC alone doesn’t work.

While OAuth 2.0 is a widely adopted and flexible authorization protocol, it has certain limitations that make it less suitable for the UK pension dashboard project:

5.1 Downsides of OAuth 2.0

OAuth 2.0 primarily focuses on client-centric authorization, where applications request access to resources on behalf of users. This model can lead to reduced user control and transparency over who accesses their data.

5.1.1 Client-Initiated Authorization:

OAuth 2.0 predominantly emphasizes client-centric authorization, wherein applications solicit access to resources on users' behalf. This model can:

  • Diminish user control.

  • Decrease transparency regarding data access.

Key Points:

  • The client, rather than the user, frequently initiates the authorization in OAuth 2.0.

  • Users often face restrictions to merely granting or denying the entire request without more refined control over data accessibility.

  • Users receive data about access requestors, boosting transparency and cultivating trust in how their financial information is managed.

5.1.2 Broad Scopes:

Scopes in OAuth 2.0 define access levels but:

  • Are frequently expansive and might not symbolize precise data elements or actions users wish to authorize.

  • Clients typically create these scopes, which users might find difficult to comprehend.

  • Scope definitions may differ between OAuth 2.0 services, leading to potential inconsistencies.

5.1.3 Consent Prompts:

While OAuth 2.0's consent prompt offers a user control level, it often:

  • Limits control to predefined scopes.

  • Doesn't always match users' specific preferences.

5.1.4 Dynamic Authorization & Delegation:

Compared to UMA 2.0:

  • OAuth 2.0 wasn't conceived with dynamic, user-led authorization.

  • It lacks mechanisms for post-authorization access permission alterations without client engagement.

  • UMA 2.0 supports dynamic authorization, empowering users to amend access policies independently.

5.1.5 Resource Owner Role:

In OAuth 2.0:

  • Users, termed "resource owners", play a more passive role than in UMA's user-centric models.

  • The user's main function is to approve or deny access, not actively manage resource access.

In contrast, UMA 2.0 provides users the autonomy to designate required scopes.

5.1.6 Consent Persistence:

OAuth 2.0 often preserves consent as long-lived access tokens, potentially hindering users from withdrawing resource access based on evolving preferences.

In UMA 2.0:

  • Users can set expirations via the UMA Authorization UI, bypassing client avenues

 old content

5.1.1 Client initiated authorization

In OAuth 2.0, the authorization process is typically initiated by the client (the application) rather than the user. The client requests access to a resource, and the user is prompted to grant or deny access. However, the user's control is often limited to granting or denying the entire request, rather than having fine-grained control over what data the client can access.

In addition to that, users are informed about who is requesting access to their resources and can make informed decisions based on this information. This transparency fosters trust and ensures that users are aware of how their financial data is being accessed.

5.1.2 Broad scopes

OAuth 2.0 uses scopes to define the level of access a client is requesting. However, scopes are often broad and may not reflect the precise data elements or actions the user wants to permit. Because in most cases, client create those scopes and user may not fully understand the implications of granting a particular scope.

Also, the scopes define varies between oauth 2.0 service and client, which leads to potential inconsistencies and complexities when dealing with scopes across different services.

5.1.3 Consent prompts

OAuth 2.0's consent prompt typically asks users to grant access to specific resources or scopes. While this is a form of user control, the granularity of control is often limited to the predefined scopes, which may not align with the user's nuanced preferences.

5.1.4 Dynamic Authorization & delegation

OAuth 2.0 was not designed with dynamic, user-driven authorization in mind. It does not provide mechanisms for users to modify access permissions post-authorization without involving the client. In contrast, UMA 2.0 supports dynamic authorization and allows users to change access policies without client intervention.

5.1.5 Resource owner rule

In OAuth 2.0, the user is often referred to as the "resource owner," but the user's role is more passive than in user-centric models like UMA. The user's primary role is to grant or deny access rather than actively manage access to their resources.

In UMA 2.0, user can choose to specify which scopes are needed

5.1.6 Consent persistence

OAuth 2.0 consent is often persisted in the form of access tokens, which may be long-lived. This can limit the user's ability to revoke access to their resources when their preferences change.

In UMA 2.0, user can do expiration through the UMA Authorization UI rather than through clients.

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.

 Old content

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

"Open banking" refers to a system where banks and other financial institutions provide access to their data through application programming interfaces (APIs). These APIs allow third-party developers to create innovative financial products and services that can interact with a bank's systems, with the explicit consent of the account holder.

In contrast, UMA 2.0 was specifically designed to address these limitations by providing a more user-centric approach to authorization. It allows users to actively manage and control access to their resources with fine-grained access policies, dynamic authorization, and more user-friendly consent management. These features make UMA 2.0 a suitable choice for scenarios where user-centric control and data protection are paramount, such as in the context of sensitive financial data like pension information.

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