Page Comparison

...

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 John, while the Front Desk role is assigned to both Tom and John.

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

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

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

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

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

  Code Block
  <ams:faultxmlns:ams="http://wso2.org/apimanager/security"> <ams:code>900910</ams:code> <ams:message>The access token does not allow you to access the requested resource</ams:message> <ams:description>Access failure for API: /orgnews, version: 1.0.0 with key: eb51eff0b4d85cda1eb1d312c5b6a3b8 </ams:description> </ams:fault>

...

• 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 Account Consent 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.  

Image RemovedImage Added

Transport-level Security

...

• 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 anytime, 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 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 easy transmission of the data obtained by another organization. If technically feasible, an individual can request to transfer his/her 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.

...