Let's take a look at the key concepts and terminology related to WSO2 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 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 services with the customers’ permission and consent. Benefits of PSD2 include:
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 services with the customers’ permission and consent.
Benefits of PSD2 include:
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.
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.
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.
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:
To view a live demo of the AISP flow of events, see AISP demo.
A Payment Initiation Service Provider (PISP) initiates credit transfers on behalf of a bank's customer.
The following diagram depicts a generic PISP flow:
To view a live demo of the PISP flow of events, see PISP demo.
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.
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.
[ Back to Top ]
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.
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.
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
The end-user who is benefited from CDR, the consumer is able to request the Data Holder to provide data.
The Data Holder (DH) is the organization that CDR is applied to provide data to the consumer. For example, a bank.
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.
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 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
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.
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
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.
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
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) .
Consent management ensures that the following scenarios take place with the consent of the respective PSU:
Consent management ensures that the following scenarios take place with the consent of the respective PSU:
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.
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.
The URL pattern can be written in either of the following forms:
The URL mapping performs a one-to-one mapping with the request URL whereas the URI template performs a pattern matching.
When an API is published, an XML definition gets created in the API Gateway. This XML file has a dedicated section for defining resources.
You can parameterize the API resource URL to map the incoming requests to the defined resource template based on the message content and the request URI. Once a URI template is matched, the parameters in the template are populated appropriately. As per the above example, a request made to the
A method is analogous to a method of a function and a resource is analogous to an object instance or a class in the object-oriented programming language.
There are a few standard methods that are defined for a resource corresponding to the standard HTTP GET, POST, PUT, and DELETE methods.
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.
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.
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.
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: 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).
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:
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 (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.
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.
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 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 refers to the security requirements at the application level. Following is a list of concepts related to application-level security:
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.
Authentication is the process used to distinctly identify a certain entity using the followingfactors:
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 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 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
- POST: This is attached to the
- GET: This is attached to the
- There are two user roles:
Managerrole is linked to both the
payment_writescopes, while the
Front Deskrole is only linked to the
Managerrole is assigned only to Charlie, while the
Front Deskrole 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
Managerrole, the user will only be granted a token bearing the
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.
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
Front Deskuser roles. If Alex tries to access the POST operation, there will be an HTTP 403 Forbidden error as follows:
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.
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:
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
requested scope, and a
redirection URIto 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 tokenfrom the authorization server's token endpoint by including the
authorization codereceived in the previous step. When making the request, the client authenticates with the authorization server. It then includes the
redirection URIused to obtain the
authorization codefor verification. The authorization server authenticates the client, validates the
authorization code, and ensures that the redirection URI matches the
URIused to redirect the client from the authorize endpoint in the previous response. If valid, the authorization server responds back with an
access tokenand, optionally, a
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
authorization grant. It requires the base64 encoded string of the
- 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.
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.
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
. OIDC utilizes the OAuth2 Authorization Code Grant and revolves around three types of actors.
|OIDC Actor||OAuth2 Nomenclature||Description||Example|
|End User||Resource Owner||This is the PSU who gets authenticated.||Bank Customer|
|Relying Party (RP)||Client||This is the client application, e.g., TPP application that requires to authenticate the PSU and obtain the claims regarding the PSU.||An application developed by an AISP|
|OpenID Provider (OP)||Authorization Server||This is an identity provider (IDP) that authenticates the PSU and provides claims regarding the PSU to the Relying Party.||WSO2 Open Banking IAM component|
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 codeto grant permission for the RP application.
- Token Endpoint: This endpoint generates
access tokensusing the
authorization codegenerated at the Authorization Endpoint for ROs.
- UserInfo Endpoint: This endpoint provides claims related to a PSU upon receiving a valid
- 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.
|Authorization Flow||Description||Response Type|
|Authorization Code Flow|
In this flow, first an
This flow is more suitable for the RPs that can share a
In this flow, an
This flow is more suitable for the browser-based RP applications.
This flow is a combination of both the Authorization Code Flow and Implicit Flow.
In this flow,
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 secretfor the applications registered at the WSO2 Open Banking Developer Portal.
- Application Access Token Generation: In this step, the TPPs obtain the
application access tokensfrom the Token Endpoint that is exposed via the Token API. First, the TPPs create the
client assertionsby utilizing their public certificates. This enables the ASPSPs to authenticate the TPPs. Subsequently, the TPPs generate the
application access tokensusing 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 IDby utilizing the
application access token. In WSO2 Open Banking, the
Consent IDis represented as either the
AccountRequest ID(AISP flow) or
Payments ID(PISP flow).
- Authorization Code Generation: This involves the TPP application obtaining the
authorization codesfrom the Authorization Endpoint that is exposed via the Authorize API. In this step, the
Consent IDis utilized to create a
request objectin 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 tokenfor the generated
authorization code. The PSUs can utilize this
user access tokento call the Account Information API (AISP flow) and Payment API (PISP flow) and proceed.
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.
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.
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: 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 4 - GDPR Compliant Consent Design
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:
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 4 - GDPR Compliant Consent Design
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.
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.