Key Concepts

Let's take a look at the key concepts and terminology related to WSO2 Open Banking.

• Open Banking

• Payment Service Directives

• PSD2

  • PSU

  • PSP

    • ASPSP

    • AISP

    • PISP

    • PIISP/CBPII

• Consumer Data Right 

  • Consumer Data Standards

  • ACCC

  • Consumer

  • Data Holder 

  • Data Recipient

  • CPS 234

• Fintech

• Open Data

• WSO2 Open Banking

  • Components

  • User Types

  • Client Registration / TPP Onboarding

  • Consent Management

  • Mediation

• APIs

  • API Resources

  • API Lifecycle

  • API Visibility

  • API Documentation

  • API Throttling 

  • OpenAPI Specification

• Applications

• Security

  • Application-level security

    • Encryption

    • Consumer Authentication

    • Authorization

    • Role-based Access Control

    • Scopes

    • Access Tokens

    • Grant Types

    • Certificates

    • OIDC

  • Transport-level Security

    • CORS

  • GDPR

    • Personal Data

    • Processing

    • Controller and Processor

    • The Rights of Individuals

Open Banking

Open banking has been introduced to make banking a more competitive business. Its main goals are offering greater financial transparency, a shared chance of success for all financial service providers, and more innovative services to the consumers.

The current banking practice involves the customer or merchant to maintain separate relationships with different financial institutions in order to achieve their financial goals. Open banking introduces a more consolidated experience to the customer by allowing banks to expose their functionality via APIs.

Payment Service Directives

The Payment Services Directives, also known as PSD and PSD2, are two pieces of legislation (European Union directives) administered by the European Commission (Directorate General Internal Market) to regulate payment services and payment service providers throughout the European Union and European Economic Area (EEA).

PSD2

PSD2 is the revised Payment Service Directive legislation administered by the European Commission and mandated in 2009. PSD2 requires Europe’s banks to give regulated third-party providers (TPPs) access to customers’ account information and payment initiation with the customers’ permission and consent.

Benefits of PSD2 include:

• Customers can manage their finances using third-party applications. For example, pay your bills using social media accounts.

• More consumer choices and better online and mobile payment methods.

• More opportunities for financial technology companies to introduce new and innovative banking services.

• Enhanced payment security.

• Ability to standardize the payment systems and impose limits on transaction fees to ensure lower costs for the consumers.

PSU

A PSU (Payment Service User) is a person who makes use of a payment service in the capacity of either a payer, payee, or both. 

PSP

A Payment Services Provider (PSP) is an entity which carries out regulated payment services, including AISPs, PISPs, CBPIIs and ASPSPs.

ASPSP

An Account Servicing Payment Service Provider (ASPSP) is a PSP that provides and maintains a payment account for a payer. Examples of ASPSPs are banks and credit card issuers. The ASPSPs are obligated to grant access to the account and transaction data on their customers’ payment accounts through APIs. 
TPP

A Third-Party Provider (TPP) is an authorized third-party that allows merchants to accept a wide variety of payments through a single channel/third-party application, and manage the entire transaction process from start to finish. This means the TPP is responsible for the transaction flow starting from the moment a customer inputs the credit card details to the moment the funds appear in the merchant's bank account. In this process, the bank continues to be the gatekeeper of the customer's information and requires the third-party to produce a security token in order to access the customer's bank details.

A TPP can be categorized into the following types: AISP, PISP, and PIISP. The customer's bank too can offer AISP and PISP services. 

AISP

An Account Information Service Provider (AISP) provides an aggregated view of all the accounts and past transactions that a customer has with different banks. To provide this view to the customer, the AISP should have authorization from the customer to view the corresponding transaction and balance information of all the payment accounts. The AISPs can also provide the facility to analyze the customer's spending patterns, expenses, and financial needs. Unlike a PISP, an AISP cannot transfer funds from a payment account. The following diagram depicts a generic AISP flow:

Open

To view a live demo of the AISP flow of events, see AISP demo.

PISP

A Payment Initiation Service Provider (PISP) initiates credit transfers on behalf of a bank's customer.

The following diagram depicts a generic PISP flow:

Open

To view a live demo of the PISP flow of events, see PISP demo.

PIISP/CBPII

A Payment Instrument Issuer Service Provider (PIISP) is a PSP that verifies the coverage of a given payment amount of the PSU's account. Examples of PIISPs are the banks and credit card issuers that are obligated to verify whether the given payment amount can be covered by the PSU's account through APIs.

Card Based Payment Instrument Issuer (CBPII) is a PSP (ASPSP/TPP) that issues payment instruments based on cards. Those cards can be used to initiate a payment transaction between an ASPSP and another PSP.

Consumer Data Right 

The Australian Government introduced the Consumer Data Right (CDR) to give consumers more control over their data. CDR provides customers and small businesses a choice about how their data is shared with third parties and sets standards for a whole industry about what data should be made available safely. In doing so, CDR encourages competition between service providers, leading to better prices for customers and more innovative products and services.

The CDR will be rolled out sector-by-sector, starting with the banking sector. Further information on the CDR is available on the Treasury website at https://treasury.gov.au/consumer-data-right .

Consumer Data Standards

The Consumer Data Standards (CDS) are the technical standards produced by Data61, which is the Data Standards Body that provides guidance for the banks/Data Holders on how to implement the CDR. These standards enable consumers to access and direct the sharing of data about them with third parties flexibly and simply, and in ways that ensure security and trust in how that data is being accessed and used.

ACCC

The Australian Competition and Consumer Commission (ACCC) is the lead regulator for the CDR regime, and it has roles and functions that include:

• Drafting rules to implement and govern the CDR in each sector

• Accrediting entities to receive data

• Managing an online register of accredited data recipients and data holders through Dynamic Client Registration (Client Registration)

• Providing education and guidance on the CDR

• Recommending to government future sectors to be brought within the CDR

• Compliance and enforcement activities

Consumer

The end-user who is benefited from CDR, the consumer is able to request the Data Holder to provide data.

Data Holder 

The Data Holder (DH) is the organization that CDR is applied to provide data to the consumer. For example, a bank.

Data Recipient

A Data Recipient (DR) is an accredited party that is able to request CDR data from a Data Holder with the consent of the consumer. 

CPS 234

Cross-industry Prudential Standards 234 Information Security (CPS 234) is a mandatory regulation issued by the Australian Prudential Regulatory Authority (APRA). The APRA regulated entities and the information assets managed by them and associated third parties should comply with CPS 234. WSO2 Open Banking is not an APRA regulated entity, but the solution can be categorized as a third-party provider that provides information assets to regulated entities.

Fintech

Fintech is another name for financial technology and is often used to refer to a business that offers new and innovative financial services using software and modern technology.

Fintechs thrive to offer various financial services like money transfers, payments, and lending in fast and easy ways to keep up with the requirements of the modern-day, tech-savvy, digitally advanced customers. Due to this reason, Fintechs have become quite a competitive challenge to banks that have more rigid, process-oriented structures.

Open Data

Open data is data that is freely available and can be used, reused, and distributed freely by any party. Just like movements such as open-source, there is no copyright, patent, or any other methods of control over open data. At most, the user is required to attribute and/or adhere to share-alike licensing. 

WSO2 Open Banking

Components

WSO2 Open Banking is geared with the following core functionality:

• API Management: This supports securely exposing data to third-parties with the ability to comply to open banking specifications. The API management component consists of the following:

  • API Publisher: This is the API publishing portal (UI) used by API creators and API publishers to create, publish, govern APIs.

  • API Store: This is the developer portal (UI) used by API consumers/ subscribers to access the published and prototyped APIs.

  • Admin Portal: This is the UI used by admins for administrative purposes.

  • Management Console: This is the UI used by super admins to manage the solution. 

  • API Gateway: This a proxy that secures, protects, manages, and scales API calls. It intercepts API requests, applies policies, e.g. throttling, and manages API statistics. Upon validation of a policy, the API Gateway passes web service calls to the actual backend. If the service call is a token request, the API Gateway passes it directly to the Key Manager.

  • Key Manager: This component manages all the access token related operations.

  • Traffic Manager: This helps users to regulate API traffic, make APIs and applications available to consumers at different service levels, and secure APIs against security attacks, e.g. DoS attacks.

  • Analytics: This enables monitoring and recording of API-level usage through statistical visualizations with statistical graphs, an alerting mechanism for predetermined events, and log analysis.

• Identity and Access Management (IAM): This enables compliance with the Regulatory Technical Standards (RTS) of the PSD2 regulations, including SCA and user consent management.

• Integration: This provides required integration points to integrate with core banking systems and other related third-party systems.

User Types

Following are the user types/roles that are available in WSO2 Open Banking:

• Super Admin: This is the WSO2 Open Banking provider that hosts and manages the overall functional aspects of the WSO2 Open Banking system, e.g., Bank infra/IT. A super admin is responsible for creating user roles in the system, assign them to users, managing databases, security, etc. 

• Admin: An Admin manages the overall functional aspects of WSO2 Open Banking, e.g., Bank IT Manager. 

• Manager: They are typically bank's decision makers and bank infrastructure (BI) staff.

• API Creator: This is a technical role capable of understanding the technical aspects of the APIs, e.g., interfaces, documentation, and versions, and provisioning APIs. The API creators use the API Store to consult ratings and feedback provided by API users. An API creator can add APIs to the API Store, but cannot manage their lifecycles.

• API Publisher: An API publisher manages a set of APIs across the enterprise or business unit and controls the API lifecycle, subscriptions, and monetization aspects, i.e., Bank API Publisher, Bank API Product Manager. The API publisher is also interested in usage patterns for APIs and has access to all API statistics. 

• API Consumer: This is an API subscriber that uses the API Store to discover APIs, read the documentation and forums, rate/comment on the APIs, subscribes to APIs, obtain access tokens, and invoke the APIs, i.e., PISP App Developer, AISP App Developer, Fintech App Developer).

• End User: These are typically retail and corporate PSUs. 

• Observer: These are typically regulators interested in performance and/or compliance aspects. 

• App Admin: These are TPP decision makers, AISPs, and  PISPs.

Client Registration / TPP Onboarding

• PSD2: Third-Party Providers (TPPs) can create third-party applications to facilitate banking services exposed via banking APIs. A TPP can play the role of a PISP/AISP/CBPII or a combination of those roles.

• CDR: Data Recipients (DRs) can create applications to facilitate banking services exposed via Bank APIs. The DRs are subject to thorough verification before connecting them with the banks/Data Holders. This verification includes a comprehensive sign-up process at the API Store, the developer portal of WSO2 Open Banking. For a DR to start providing open banking services, it has to be registered under the Australian Competition and Consumer Commission (ACCC) .

The TPPs are subject to thorough verification before connecting them with the banks/ASPSPs. This verification includes a comprehensive sign-up process at the API Store; the developer portal of WSO2 Open Banking. For a TPP to start providing open banking services, it has to be registered under a Competent Authority, which is a regulatory body that authorizes and supervises the open banking services delivered by the TPP

Consent Management

Consent management ensures that the following scenarios take place with the consent of the respective PSU:

• Accessing the PSU's account and transaction data by AISPs

• Processing online payments on behalf of PSUs by PISPs

Mediation

When performing transactions, it is inevitable for systems that communicate in various protocols and formats to communicate with each other. Mediation enables exchanging of messages between such disparate systems with less complexity. Message mediation encompasses message routing, message filtering, message transformation, protocol switching, etc. WSO2 Open Banking facilitates message mediation that enables integrating with core banking systems and other internal banking services including legacy systems. 

APIs

Application Programming Interfaces (API) is a mechanism that enables exposing software functionality without revealing its implementation. APIs enable software applications to interact with each other and exchange data. WSO2 Open Banking supports REST, SOAP, and WebSocket APIs. 

API Resources

An API is made up of one more resource, each of which handles a particular type of request. A resource is defined with a URL pattern and a set of methods that operate on it.

API Lifecycle

APIs have their own lifecycles that are independent of the backend services they rely on. An API lifecycle is exposed in the API publisher and is managed by the API publisher role.

The following stages are available in the default API lifecycle: 

• CREATED: In this stage, the API metadata are added to the API Store but the API is not deployed in the API Gateway. Therefore, the API is not visible in the API Store to subscribers.

• PROTOTYPED: The APIs in this stage are deployed and published in the API Store as prototypes. A prototype API is usually a mock implementation made public in order to get feedback about its usability. Users can invoke the API without a subscription.

• PUBLISHED: These APIs are visible in the API Store and available for subscription.

• DEPRECATED: Deprecated APIs are not available for subscription. But these APIs are still deployed in the API Gateway and are available at runtime to existing subscribers. Existing subscribers can continue to use it as usual until the API is retired.

• RETIRED: These APIs are unpublished from the API Gateway and deleted from the API Store.

• BLOCKED: Access to the API is temporarily blocked. Runtime calls are blocked and the API is not shown in the API Store anymore.

API Visibility

Visibility settings prevent certain user roles from viewing and modifying APIs created by another user role.

• Public: These APIs are visible to all anonymous (users who use APIs without signing in) and registered users, and can be advertised in multiple stores, i.e., central and non-WSO2 API Stores.

• Restricted by Roles: These APIs are only visible to user roles that you specify. 

The API visibility levels apply to users in different roles in the following manner:

• API Creator/API Publisher: These users can see all the APIs in the API Store even if you restrict access to them. This is because these roles have permission to view and edit all the APIs in the API Publisher.

• Anonymous: These users can only see public APIs.

• Registered: These users can see all the public APIs as well as the APIs accessible to their user roles.

API Documentation

WSO2 Open Banking facilitates adding documentation to APIs. API documentation helps API subscribers to understand the functionality of the API and API publishers to market their APIs better and sustain the competition. By default, the visibility of an API documentation is as same as its API visibility.

API Throttling 

Throttling allows you to limit the number of successful hits to an API during a given period of time, typically in cases such as the following:

• To protect your APIs from common types of security attacks such as a denial of service (DoS)

• To regulate traffic according to infrastructure availability

• To make an API, application, or a resource available to a consumer at different levels of service

You can define throttling at the API, application, and resource levels. The final request limit granted to a given user for a given API is ultimately defined by the consolidated output of all the applicable throttling tiers.  The throttling tiers are also referred to as Service-level agreements (SLAs). 

OpenAPI Specification

OpenAPI (formerly known as Swagger) is a 100% open source, standard, language-agnostic specification and a complete framework for describing, producing, consuming, and visualizing RESTful APIs, without the need of a proxy or third-party services. OpenAPI allows consumers to understand the capabilities of a remote service without accessing its source code, and interact with the service with a minimal amount of implementation logic. OpenAPI describes a service in the same way that interfaces describe lower-level programming code. 

The Swagger UI is a dependency-free collection of HTML, JavaScript, and CSS that dynamically generates documentation from an OpenAPI-compliant API. OpenAPI-compliant APIs give you interactive documentation, client SDK generation and more discoverability. The Swagger UI has JSON code, and its UI facilitates easier code indentation, keyword highlighting and shows syntax errors on the fly. You can add resource parameters, summaries and descriptions to your APIs using the Swagger UI. The WSO2 Open Banking API management component has an integrated Swagger UI. For more information, see the OpenAPI Specification version 2.0 (formerly known as Swagger RESTful API Documentation Specification) and OpenAPI Specification version 3.0.0.

Applications

An application is an intermediary that sits between an API and its consumer. API consumers use applications to subscribe to APIs and consume them.

An API consumer can subscribe to multiple APIs using a single application. Thus, it acts as a logical collection of API subscriptions and decouples the API consumer from the APIs. Each application can be associated with different Service Level Agreement (SLA) levels. This is enabled by attaching an application with throttling tiers that determine the maximum number of API calls allowed during a given duration.

Applications therefore enable:

• Generating and using a single key for multiple APIs

• Subscribing to the same API multiple times with different tiers/Service Level Agreement (SLA) levels

WSO2 Open Banking comes with a pre-created default application, which allows unlimited access by default. You can also create your own applications. 

Security

Security refers to the means through which computer systems are protected from damage and disruption without being compromised to risks and vulnerabilities. WSO2 Open Banking implements security at the application level and transport level.

Application-level security

Application-level security refers to the security requirements at the application level. Following is a list of concepts related to application-level security:

Encryption

Encryption is the process of translating/encoding data/messages (plaintext) using an algorithm (cipher) into a secret code (ciphertext) that can only be accessed by authorized entities with a secret key or a password.

Consumer Authentication

Authentication is the process used to distinctly identify a certain entity using the following factors:

• Knowledge factor: This is something the user knows, e.g., password, PIN, and security question.

• Ownership factor: This is something the user has, e.g., ATM card, identity card, mobile phone, and security token.

• Inherence factor: This is something the user is/does, i.e., biometrics.  

Authentication is implemented in either of the following forms:

• Multi-factor Authentication: Multi-factor authentication (MFA) utilizes two or more factors to authenticate an entity.

• Two-factor Authentication: Two-factor authentication (2FA) is a subset of MFA. It utilizes two factors to authenticate an entity.

• Strong Customer Authentication: Strong customer authentication (SCA) is another name for 2FA and MFA. It simply means that two or more elements are used to authenticate a user. These elements are based on the same categories used in MFA: customer's knowledge, possession, and inherence. The idea is that these elements are independent so that the breach of one does not compromise the others.

• Adaptive Authentication: Adaptive authentication allows to adjust the authentication strength based on the context at hand. So, that SCA can be enforced only when it is necessary.

• Federated Authentication: Federated authentication provides a user with access to multiple systems across different enterprises. Subscribers can use the same identification data to gain access to all enterprises in a group at once. 

• Out-of-band Authentication:  Out-of-band authentication (OOB) is an anti-fraud measure that is popular among financial institutions. It triggers an alert through a channel such as a mobile device to the customers when a transaction occurs in their accounts. This alert is typically done through a phone call or a message.

Authorization

Authorization is the process via which an entity is granted permission to access to another entity, e.g., data, resources, and system. In general, authorization takes place subsequent to authentication. WSO2 Open Banking uses role-based access control (RBAC) and scopes to implement authorization.

Role-based Access Control

Role-based access control (RBAC) is a type of access control that restricts access to authorized users based on their role.

Scopes

Scopes enable fine-grained access control to API resources based on user roles. When a user invokes the API, the user's OAuth2 bearer token cannot grant access to any API resource beyond its associated scopes.To illustrate the functionality of scopes, let's assume the following:

• There is an API with the following resources:

  • GET: This is attached to the payment_read scope.

  • POST: This is attached to the payment_write scope.

• There are two user roles: Manager and Front Desk.

• The Manager role is linked to both the payment_read and payment_write scopes, while the Front Desk role is only linked to the payment_read scope.

• The Manager role is assigned only to Charlie, while the Front Desk role is assigned to both Alex and Charlie.

• Alex requests a token through the Token API as grant_type=password&username=alex&password=xxxx&scope=payment_read payment_write. However, as Alex is not in the Manager role, the user will only be granted a token bearing the payment_read scope.

  "scope":"payment_read","token_type":"bearer","expires_in":3299, "refresh_token":"8579facb65d1d3eba74a395a2e78dd6", "access_token":"eb51eff0b4d85cda1eb1d312c5b6a3b8"

   

  • Next, Charlie requests a token as grant_type=password&username=charlie&password=charlie123&scope=payment_read payment_write. As Charlie has both the roles assigned, the token will bear both requested scopes.

    "scope":"payment_read payment_write", "token_type":"bearer", "expires_in":3299, "refresh_token":"4ca244fb321bd555bd3d555df39315", "access_token":"42a377a0101877d1d9e29c5f30857e"

  • This means that Alex can only access the GET operation of the API, while Charlie can access both as the scope is assigned to both the Manager and Front Desk user roles. If Alex tries to access the POST operation, there will be an HTTP 403 Forbidden error as follows:

Access Tokens

An access token is a simple string that is passed as an HTTP header of a request, e.g., "Authorization: Bearer NtBQkXoKElu0H1a1fQ0DWfo6IX4a". WSO2 Open Banking supports two types of access tokens for authentication to ensure better security, e.g., preventing DoS attacks:

• Application access tokens: These tokens identify and authenticate an entire application. Thus, you can invoke all the APIs associated with an application using a single application access token.

• User access tokens: These tokens identify the end-user of an application, e.g., the end-user of a mobile application deployed on a different device.

Access tokens authenticate API users and applications and ensure better security, e.g., preventing DoS attacks. If a token that is passed with a request is invalid, the request is discarded in the first stage of processing. Access tokens work equally well for SOAP and REST calls. 

Grant Types

Access tokens grant access to protected API resources. The level of access granted by each access token is determined by the method (known as grant type) used to generate the access token. There are several grant types used in WSO2 Open Banking:

• Authorization Code Grant:  

  • The client initiates the flow by directing the resource owner's user-agent to the authorization endpoint (you can use the /authorize endpoint for the authorization code grant type of OAuth 2.0). It includes the client identifier, response_type, requested scope, and a redirection URI to which the authorization server sends the user-agent back after granting access. The authorization server authenticates the resource owner (via the user-agent) and establishes whether the resource owner granted or denied the client's access request. Assuming the resource owner grants access, the authorization server then redirects the user-agent back to the client using the redirection URI provided earlier. The redirection URI includes an authorization code. 

  • The client then requests an access token from the authorization server's token endpoint by including the authorization code received in the previous step. When making the request, the client authenticates with the authorization server. It then includes the redirection URI used to obtain the authorization code for verification. The authorization server authenticates the client, validates the authorization code, and ensures that the redirection URI matches the URI used to redirect the client from the authorize endpoint in the previous response. If valid, the authorization server responds back with an access token and, optionally, a refresh token.

  • Instead of requesting authorization directly from the resource owner (resource owner's credentials), in this grant type, the client directs the resource owner to an authorization server. The authorization server works as an intermediary between the client and resource owner to issues an authorization code, authenticate the resource owner and obtain authorization. As this is a redirection-based flow, the client must be capable of interacting with the resource owner's user-agent (typically a Web browser) and receiving incoming requests (via redirection) from the authorization server.

• NTLM Grant: NTLM is the successor of the authentication protocol in Microsoft LAN Manager (LANMAN), an older Microsoft product, and attempts to provide backward compatibility with LANMAN. You can obtain an access token to your API in a WSO2 Open Banking instance running on Windows by providing a valid NTLM token as an authorization grant. 

• Password Grant: You can obtain an access token by providing the resource owner's username and password as an authorization grant. It requires the base64 encoded string of the consumer-key:consumer-secret combination. 

• SAML Extension Grant: SAML 2.0 is an XML-based protocol. It uses security tokens containing assertions to pass information about an end-user between a SAML authority and a SAML consumer. A SAML authority is an identity provider (IdP) and a SAML consumer is a service provider (SP). Enterprise applications that have SAML2 based SSO infrastructures sometimes need to consume OAuth-protected resources through APIs. However, these apps prefer to use the existing trust relationship with the IdP, even if the OAuth authorization server is entirely different from the IdP. WSO2 Open Banking leverages this trust relationship by exchanging the SAML2.0 token to an OAuth token with the authorization server. It acts as the OAuth authorization server. 

• Client Credentials Grant: Client credentials can be used when the authorization scope is limited to the protected resources belonging to the client. Client credentials are used as an authorization grant when the client requests access to protected resources based on an authorization previously arranged with the authorization server. The client application requests an access token from the authorization server, authenticating the request with its client key and client secret. If the client is successfully authenticated, an access token is returned. 

• Kerberos OAuth2 Grant: Kerberos is a security protocol that has support built into various operating systems and open-source distributions, e.g., Ubuntu, Windows, RedHat, and Open Solaris. In addition, a majority of browsers support some Kerberos functions as well. As WSO2 Open Banking uses the OAuth 2.0 protocol, the Kerberos OAuth2 grant type allows organizations to exchange a Kerberos ticket for an OAuth 2.0 token. Thereby, allowing organizations to re-use their existing Kerberos infrastructure, while easier adopting OAuth 2.0 within these organizations. 

• Refresh Token Grant: After an access token is generated, sometimes you might have to renew the old token due to expiration or security concerns. You can renew an access token using a refresh token, by issuing a REST call to the Token API with the following parameters. With this grant type, the refresh token acts as credentials that are issued to the client by the authorization server. Issuing a refresh token is optional. If the authorization server issues a refresh token, it is included when issuing an access token. Refresh tokens are issued for all other grant types other than the implicit grant as recommended by the OAuth 2.0 specification.  

Certificates

A certificate (also known as an SSL certificate or digital certificate) is an encryption tool issued by a trusted certification authority (CA) that encrypts data transmitted between a client and a server. Certificates are used for public-key encryption in Public Key Infrastructure (PKI). In WSO2 Open Banking a TPP must forward a certificate to the ASPSP so that when the TPP sends an application access token request, the ASPSP can verify the authenticity of the request using the shared certificate. A keystore is a repository that contains multiple certificates. 

OIDC

OpenID Connect (OIDC) is an identity layer that functions on top of the OAuth2 protocol. It enables the Client/TPP applications to verify the end users/PSUs, and obtain the basic PSU profile information via  claims . OIDC utilizes the OAuth2 Authorization Code Grant and revolves around three types of actors. 

The OP of the ASPSP generates an identity token named ID Token to represent the PSU's identity. The ID Tokens are created in JSON Web Token (JWT) format and signed using the JSON Web Signature (JWS) to accomplish integrity and non-repudiation.

There are four types of endpoints, i.e., HTTP resources in OIDC:

• Authorization Endpoint: This is the OP endpoint that authenticates the PSU. When a PSU attempts to access the account details or initiate a payment via an RP application, the PSU gets directed to the Authorization Endpoint. The Authorization Endpoint authenticates the PSU and generates an authorization code to grant permission for the RP application. 

• Token Endpoint: This endpoint generates ID Tokens and access tokens using the authorization code generated at the Authorization Endpoint for ROs.

• UserInfo Endpoint: This endpoint provides claims related to a PSU upon receiving a valid access token. 

• Redirect Endpoint: This endpoint redirects the PSU's browser back to the RO application. 

There are three types of OIDC flows that RPs can use to request OPs to authenticate PSUs.

WSO2 Open Banking utilizes the Hybrid Flow to authenticate the PSUs. Following are the high-level steps that are involved in this flow:

• User Sign Up: The authorized entities of the RP/TPP registers at the WSO2 Open Banking Developer Portal.

• Application Registration: The TPPs register their open banking applications at the WSO2 Open Banking Developer Portal. This includes the uploading of the public certificate of the TPP. 

• Key Generation: The TPPs request the client key and client secret for the applications registered at the WSO2 Open Banking Developer Portal.

• Application Access Token Generation: In this step, the TPPs obtain the application access tokens from the Token Endpoint that is exposed via the Token API. First, the TPPs create the client assertions by utilizing their public certificates. This enables the ASPSPs to authenticate the TPPs. Subsequently, the TPPs generate the application access tokens using the preferred grant types. 

• Consent Initiation: The TPPs send the Account Initiation (AISP flow) or Payment Initiation (PISP flow) call to the Resource Endpoint. The Resource Endpoint responds with a Consent ID by utilizing the application access token. In WSO2 Open Banking, the Consent ID is represented as either the AccountRequest ID (AISP flow) or Payments ID (PISP flow). 

• Authorization Code Generation: This involves the TPP application obtaining the authorization codes from the Authorization Endpoint that is exposed via the Authorize API. In this step, the Consent ID is utilized to create a request object in JWT that is in turn utilized to call the Authorize API. The Authorize API facilitates the PSUs to approve the account access (AISP flow) or online payment (PISP flow). 

• User Access Token Generation: This involves obtaining an OAuth2 token for the generated authorization code. The PSUs can utilize this user access token to call the Account Information API (AISP flow) and Payment API (PISP flow) and proceed.  

Transport-level Security

Transport-level security (TLS) is a mechanism that secures internet and Intranet communications. WSO2 Open Banking uses certificates, and keystores to implement transport-level security. 

CORS

Cross-Origin Resource Sharing (CORS) is a mechanism that allows accessing restricted resources, i.e., fonts, images, scripts, videos, and iframes from domains outside the domain from which the requesting resource originated. By default, web browsers apply the same-origin policy to avoid interactions between different origins. CORS defines a way in which a browser and a server can interact to determine whether or not it is safe to allow the cross-origin requests.

GDPR

The General Data Protection Regulation (GDPR) is a new legal framework formalized in the European Union (EU) in 2016 and comes into effect from 28, May 2018. GDPR effectively replaces the previously used EU Data Protection Directive (DPD). 

GDPR is applicable to any individual living in the EU and considers the following two aspects:

1. Processing of personal data belonging to an individual living in the EU

2. Free movement of personal data belonging to an individual living in the EU within the region

If you are new to GDPR, we recommend that you take a look at our tutorial series on Creating a Winning GDPR Strategy.

• Part 1 - Introduction to GDPR

• Part 2 - 7 Steps for GDPR Compliance

• Part 3 - Identity and Access Management to the Rescue

• Part 4 - GDPR Compliant Consent Design

For more resources on GDPR, see the white papers, case studies, solution briefs, webinars, and talks published on our WSO2 GDPR homepage. You can also find the original GDPR legal text here.

Personal Data

Personal data or Personally Identifiable Information (PII) is any information that identifies a natural person, e.g., username, email address, IRC username, cookie, IP address, Radio Frequency Identification (RFID) tags, and biometric.

Processing

Data processing involves the following:

• Collecting personal data

• Recording personal data

• Organizing, cataloging, and structuring personal data

• Storing personal data

• Adapting or altering personal data

• Retrieving personal data 

• Consultation based on personal data

• Personal data disclosure by transmission

• Disseminating or making available the personal data

• Alignment or combining personal data

• Restricting personal data

• Erasure or destruction of personal data

Processing or movement of data belonging to a non-human such as a legal entity, business organization, an animal, and personal data belonging to a deceased individual are not covered under the GDPR regulations.

Controller and Processor

The controller is a natural or legal person, public authority, agency or any other body that alone or jointly with others, determines the purposes and means of the processing of personal data. A processor is a natural or legal person, public authority, agency or any other body that processes personal data on behalf of the controller.

The Rights of Individuals

GDPR defines a very strong set of rights for individuals. It is important for both individuals and personal data processing organizations to understand these rights:

• The right of transparency and modalities: All processing activities based on personal data must be transparent to individuals. It is the responsibility of the processing organizations to make these processing details available for individuals in a clear, concise, and intelligible manner. Additionally, this information must be easily accessible and should use plain language.

• The right to be informed: Each individual should be given an adequate level of information regarding the data processing organization including the name and contact details of the organization, purpose of data processing, legal basis for the processing, intended period of personal data storage, whether an automated decision-making system is in place, other recipients of data including third parties, and rights of individuals such as right to access their data at any time, right to withdraw previous consent, and right to lodge a complaint. These details need to be provided when collecting personal data from individuals directly or indirectly. 

• The right of access: GDPR facilitates individuals to request information about data processing from a processing organization by sending a Subject Access Request (SAR). This information includes what personal data has been processed, the purpose of processing, and what data is stored within the system. It is mandatory for processing organizations to respond to SARs at the latest within one month of receipt. If the processing of SAR is complex, organizations can further extend this period by another two months, subject to notifying the individual about the extension.

• The right to rectification: An individual should have the right to require that the processing organization correct any errors in personal data processed without any delays.

• The right to be forgotten: An individual should have the right to request the processing organizations to erase personal data without any delays. When a processing organization makes personal data public, the individual can request to erase any links to copying and/or replication of personal data.

• The right to restrict processing: The individuals can request a processing organization to restrict their personal data processing. In such cases, the processing organization may continue to store the data, but the purposes for which the data can be processed are strictly limited.

• The right for notification obligation: The processing organization should notify the individual in the event of rectification, erasure or restriction of the individual's personal data in a concise manner.

• The right to data portability: An individual has the right to obtain the personal data stored in a processing organization in a structured, commonly used, and machine-readable format. This facilitates the easy transmission of the data obtained by another organization. If technically feasible, an individual can request to transfer the individual's personal data from one processing organization to another directly.

• The right to object: An individual can object the processing of the individual's personal data at any time. In such cases, the processing organization should stop the processing of affected data unless they can demonstrate legitimate grounds for continuing with the processing of the affected data.

• Rights in relation to automated decision making and profiling: An individual has the right not to be subject to decisions based solely on automated processing that significantly affect the individual. Examples of solely automated processing include online credit application, e-recruiting or e-evaluation of performance without any human intervention. 

Data Protection Officer (DPO)

The Data Protection Officer (DPO) provides necessary advice to processing organizations and act as the point of contact for individuals and supervisory authorities. DPO can be a staff member or an external contractor and must possess professional qualifications and expert knowledge to perform tasks associated with the role.