diff --git a/config.toml b/config.toml
index 1fec6e6f..3344f37a 100644
--- a/config.toml
+++ b/config.toml
@@ -39,7 +39,7 @@ anchor = "smart"
[services]
[services.googleAnalytics]
# Comment out the next line to disable GA tracking. Also disables the feature described in [params.ui.feedback].
-#id = "UA-56643615-3"
+id = "UA-56643615-3"
# Language configuration
diff --git a/content/en/_index.html b/content/en/_index.html
index e7d5b0e6..a8991ebf 100644
--- a/content/en/_index.html
+++ b/content/en/_index.html
@@ -45,8 +45,8 @@
Amplify Open Banking
{{% /blocks/feature %}}
-{{% blocks/feature icon="fa-lightbulb" title="Deployment" url="/docs/deployment/" %}}
-A guide to deploying the solution.
+{{% blocks/feature icon="fa-lightbulb" title="Configuration" url="/docs/configuration/" %}}
+A guide to configure the solution.
{{% /blocks/feature %}}
{{< /blocks/section >}}
diff --git a/content/en/docs/Configuration/Certificate Management/_index.md b/content/en/docs/Configuration/Certificate Management/_index.md
index bab1bdd4..243cbda9 100644
--- a/content/en/docs/Configuration/Certificate Management/_index.md
+++ b/content/en/docs/Configuration/Certificate Management/_index.md
@@ -7,4 +7,127 @@ date: 2021-09-02
Amplify Open Banking uses digital certificates for many security functions. The solution comes with sample certificates that can be used in non-production environments for testing purposes only. It is highly recommended to change all certificates and use official certificates signed by one of your approved Certificate Authorities.
-The following topics provide how-to instructions for managing certificates.
\ No newline at end of file
+This section provides instructions for managing certificates.
+
+## Context
+
+Mutual authentication is required for most APIs developed for Open Banking.
+
+According to the Open Banking Specification, Mutual Transport Layer Security (MTLS) client connections are required for the API Gateway Listener and Authorization Server components.
+
+See more about the Certificate Verification with MTLS in the Open Banking context in [Mutual Authentication and Certificate Verification](/docs/overview/integration/mutual-auth).
+
+## Set up the solution for MTLS with test certificates
+
+This section includes the prerequisites and tasks to setup the solution for MTLS.
+
+### Prerequisites
+
+* An OpenSSL tool is available.
+* Amplify Integration is running with Open Banking projects.
+
+### Create the root CA certificates
+
+First, some certificates must exist to generate multiples:
+
+```bash
+openssl genrsa -out ca1.key 2048
+openssl req -new -x509 -days 3650 -key ca1.key -subj "/C=US/ST=Arizona/L=Phoenix/O=Axway/CN=Axway Root CA" -out ca1.crt
+```
+
+### Create client certificates
+
+The data recipient or Third-Party Provider (TPP) applications need the client certificate for MTLS. In this section there are sample instructions to generate certificates for testing purposes.
+
+Each certificate must have one key that is signed with a previously created root certificate authority. The following configuration files are provided as examples.
+
+| tpp1.cnf |
+| ----------- |
+
+```properties
+[req]
+default_bits = 2048
+default_md = sha256
+encrypt_key = yes
+prompt = no
+string_mask = utf8only
+distinguished_name = client_distinguished_name
+req_extensions = req_cert_extensions
+
+[client_distinguished_name]
+businessCategory = Third Party Provider 1
+jurisdictionCountryName = US
+serialNumber = 18505934000140
+countryName = US
+organizationName = AXWAY
+stateOrProvinceName = Arizona
+localityName = Phoenix
+organizationalUnitName = 00000000-0000-0000-0000-000000000002
+UID = 00000000-0000-0000-0000-000000000002
+commonName = tpp1.demo.axway.com
+
+[req_cert_extensions]
+basicConstraints = CA:FALSE
+subjectAltName = @alt_name
+keyUsage = critical,digitalSignature,keyEncipherment
+extendedKeyUsage = clientAuth
+
+[alt_name]
+DNS = tpp1.demo.axway.com
+```
+
+| tpp2.cnf |
+| ----------- |
+
+```properties
+[req]
+default_bits = 2048
+default_md = sha256
+encrypt_key = yes
+prompt = no
+string_mask = utf8only
+distinguished_name = client_distinguished_name
+req_extensions = req_cert_extensions
+
+[client_distinguished_name]
+businessCategory = Third Party Provider 2
+jurisdictionCountryName = US
+serialNumber = 18505934000140
+countryName = US
+organizationName = AXWAY
+stateOrProvinceName = Arizona
+localityName = Phoenix
+organizationalUnitName = 00000000-0000-0000-0000-000000000002
+UID = 00000000-0000-0000-0000-000000000002
+commonName = tpp2.demo.axway.com
+
+[req_cert_extensions]
+basicConstraints = CA:FALSE
+subjectAltName = @alt_name
+keyUsage = critical,digitalSignature,keyEncipherment
+extendedKeyUsage = clientAuth
+
+[alt_name]
+DNS = tpp2.demo.axway.com
+```
+
+Then execute the following commands to generate the required certificates:
+
+```bash
+openssl req -new -newkey rsa:2048 -nodes -out tpp1.csr -keyout tpp1.key -config ./tpp1.cnf
+openssl x509 -req -days 3650 -in tpp1.csr -CA ca1.crt -CAkey ca1.key -CAcreateserial -out tpp1.crt
+openssl req -new -newkey rsa:2048 -nodes -out tpp2.csr -keyout tpp2.key -config ./tpp2.cnf
+openssl x509 -req -days 3650 -in tpp1.csr -CA ca1.crt -CAkey ca1.key -CAcreateserial -out tpp2.crt
+```
+
+### Configure root CA certificates in Amplify Integration
+
+The root CA certificate (e.g., ca1.crt), must to be added in Amplify Integration:
+
+1. Import the certificate in *Manager > Security > Certificates*.
+![Certificate Import](/Images/AI-Manager-Certificates.png)
+2. Navigate to *Design > Select Project*.
+3. Update the **Governance rule** of type *Transport Policy* to add/update the Root CA.
+4. Do this for each project in which APIs are exposed via MTLS to add the Root CA.
+ * FDX_Accounts project and FDX_MTLS governance rule
+ * FDX_Authorization project and FDX_Authorization_MTLS governance rule
diff --git a/content/en/docs/Configuration/Certificate Management/jwks.md b/content/en/docs/Configuration/Certificate Management/jwks.md
deleted file mode 100644
index be0ab4db..00000000
--- a/content/en/docs/Configuration/Certificate Management/jwks.md
+++ /dev/null
@@ -1,63 +0,0 @@
----
-title: "JWKS configuration"
-linkTitle: "JWKS"
-weight: 3
-date: 2021-10-13
----
-
-Some Open Banking flows are using JSON Web Tokens (JWT) for security purposes, for example the Open Finance Brazil Payment API.
-To sign or to verify these tokens, the Open Banking solution needs keys that are stored in a JSON Web Key Set (JWKS).
-
-Each instance of the Amplify Open Banking solution has different keys that correspond to the bank and environment in use.
-
-{{% alert title="Note" color="primary" %}} The following steps are necessary only for Open Finance Brazil deployments.{{% /alert %}}
-
-## ASPSP signing certificate
-
-The ASPSP (Account Servicing Payment Service Provider, the bank or similar institution) signing certificate must be added to the authorization server to sign response messages.
-
-Follow this procedure to change the signing certificate with the appropriate values:
-
-1. Connect to the Cloudentity server and check the current authorization server signing certificate.
-
- * Replace ` by your Cloudentity server interface, and then connect to the following URL in your navigator:
- `https:///app/default/admin/openbanking_brasil/workspaces/signing-keys`.
- * Connect with your user/admin password.
- * Verify that the **Current key in use** is the default ASPSP signing certificate (what you will change with this procedure).
-
- ![CloudentitySigningKey](/Images/ACPSigningKey.PNG)
-
-2. Export the actual authorization server configuration with Cloudentity API.
- * Navigate to the Cloudentity swagger page. The previous step will keep you logged in with your credentials.
- Browse to the servers section, and then *Get authorization server*.
- `https:///api/swagger/default/openbanking_brasil/#/servers/getAuthorizationServer`.
- * Click *Try it out*.
- * Replace with your tid (tenant id) and aid (authorization server id). In Open Banking Brasil, the tid is *default* and the aid is *openbanking_brasil*
- * Execute the request.
- ![GetAuthServer](/Images/GetAuthServer.PNG)
- * Copy the response.
-
-3. Convert the ASPSP certificate from PEM to JWK.
- You can use your own tools or find tools online to execute this operation.
-
-4. Modify the response obtained in step 2 to replace the signature entry by your ASPSP JWK certificate converted in step 3.
- Use the KID that comes from Central Directory.
-
-5. Upload the configuration to the authorization server.
- * Go back to the swagger page, to the *Update authorization server* section.
- `https:///api/swagger/default/openbanking_brasil/#/servers/updateAuthorizationServer`.
- * Click *Try it out*.
- * Replace with your tid (tenant id) and aid (authorization server id). In Open Banking Brasil, the tid is *default* and the aid is *openbanking_brasil*.
- * Paste the response of the previous step 3 with the new signing certificate in the body.
- * Execute the request.
- ![PutAuthServer](/Images/PutAuthServer.PNG)
-
-6. Validate the procedure.
- * Refresh the Cloudentity interface and you will see that your ASPSP signature key has been modified.
-
-## TPP signing certificate
-
-The TPP (Third Party Provider) signing certificates are located in the Cloudentity configuration. Connect to the Cloudentity Interface, navigate to your workspace (openbanking Brasil for Brasil specifications), and then click on the application. Click the application name of the desired TPP.
-The signing certificate is located in the OAuth tab, under client authentication, as a JSON Web Key Set. You can modify the signing certificate here, and then click *Save changes*.
-
-![TPPSignatureKey](/Images/TPPSignatureKey.PNG)
\ No newline at end of file
diff --git a/content/en/docs/Configuration/Certificate Management/mtls.md b/content/en/docs/Configuration/Certificate Management/mtls.md
deleted file mode 100644
index 73712011..00000000
--- a/content/en/docs/Configuration/Certificate Management/mtls.md
+++ /dev/null
@@ -1,216 +0,0 @@
----
-title: "MTLS configuration"
-linkTitle: "MTLS"
-weight: 2
-date: 2021-09-02
----
-
-How to change and test the certificate configurations required for Mutual Authentication.
-
-## Context
-
-Mutual authentication is required for most APIs developed for Open Banking.
-
-According to the Open Banking Specification, Mutual Transport Layer Security (MTLS) client connections are required for the Cloudentity and API Gateway Listener components. See the diagram for details on MTLS setup.
-![MTLS diagram](/Images/MTLS.svg)
-
-See more about the Certificate Verification with MTLS in Open Banking context in [Mutual Authentication and Certificate Verification](/docs/overview/integration/mutual-auth).
-
-### API Gateway MTLS
-
-The reference architecture uses an ingress controller to support the MTLS capabilities.
-
-Others possibilities are:
-
-* Use a component in front of the Kubernetes cluster to support the MTLS termination. In this condition, Axway recommends to have a component nearest the Kubernetes cluster.
-
-* Replace the nginx ingress controller by another ingress controller that supports the required features.
-
-Refer to the required features of the ingress controller in [Deployment - Prerequisites](/docs/deployment/prerequisites).
-
-{{% alert title="Note" color="primary" %}} Usage of the MTLS Listener embedded on the API-gateway configuration would require each customer to build their own Docker images, as the container maturity level does not allow us to externalize certificates.{{% /alert %}}
-
-### Cloudentity MTLS
-
-Cloudentity supports the MTLS and the root CA must be added in the component.
-
-## Setup the solution for MTLS with test certificates
-
-This section includes the prerequisites and tasks to setup the solution for MTLS.
-
-### Prerequisites
-
-* An openssl tool available.
-* A Cloudentity deployed on Kubernetes.
-* An APIM component deployed on Kubernetes.
-* Nginx Ingress Controller deployed on Kubernetes.
-
-### Create the root CA certificates
-
-First, some certificates must exist to generates multiples
-
-```bash
-openssl genrsa -out ca1.key 2048openssl req -new -x509 -days 3650 -key ca1.key -subj "/C=BR/ST=São Paulo/L=São Paulo/O=Axway/CN=Axway Root CA" -out ca1.crtopenssl genrsa -out ca2.key 2048openssl req -new -x509 -days 3650 -key ca2.key -subj "/C=BR/ST=São Paulo/L=São Paulo/O=Axway/CN=Axway Root CA" -out ca2.crt
-```
-
-### Create Client Certificates
-
-The Data Recipient or Third-Party Provider (TPP) Applications need the client certificate for MTLS. In this section there are sample instructions to generate certificates for testing purposes.
-
-Each certificate must have one key that is signed with a previously created root certificate authority. These configuration files below are provided as examples.
-
-| tpp1.cnf |
-| ----------- |
-
-```properties
-[req]
-default_bits = 2048
-default_md = sha256
-encrypt_key = yes
-prompt = no
-string_mask = utf8only
-distinguished_name = client_distinguished_name
-req_extensions = req_cert_extensions
-
-[client_distinguished_name]
-businessCategory = Third Party Provider 1
-jurisdictionCountryName = BR
-serialNumber = 18505934000140
-countryName = BR
-organizationName = AXWAY
-stateOrProvinceName = SP
-localityName = São Paulo
-organizationalUnitName = 00000000-0000-0000-0000-000000000002
-UID = 00000000-0000-0000-0000-000000000002
-commonName = tpp1.demo.axway.com
-
-[req_cert_extensions]
-basicConstraints = CA:FALSE
-subjectAltName = @alt_name
-keyUsage = critical,digitalSignature,keyEncipherment
-extendedKeyUsage = clientAuth
-
-[alt_name]
-DNS = tpp1.demo.axway.com
-```
-
-| tpp2.cnf |
-| ----------- |
-
-```properties
-[req]
-default_bits = 2048
-default_md = sha256
-encrypt_key = yes
-prompt = no
-string_mask = utf8only
-distinguished_name = client_distinguished_name
-req_extensions = req_cert_extensions
-
-[client_distinguished_name]
-businessCategory = Third Party Provider 2
-jurisdictionCountryName = BR
-serialNumber = 18505934000140
-countryName = BR
-organizationName = AXWAY
-stateOrProvinceName = SP
-localityName = São Paulo
-organizationalUnitName = 00000000-0000-0000-0000-000000000002
-UID = 00000000-0000-0000-0000-000000000002
-commonName = tpp2.demo.axway.com
-
-[req_cert_extensions]
-basicConstraints = CA:FALSE
-subjectAltName = @alt_name
-keyUsage = critical,digitalSignature,keyEncipherment
-extendedKeyUsage = clientAuth
-
-[alt_name]
-DNS = tpp2.demo.axway.com
-```
-
-Download these files:
-
-* [tpp1.cnf](https://axway-open-banking-docs.netlify.app/sample-files/tpp1.cnf)
-* [tpp2.cnf](https://axway-open-banking-docs.netlify.app/sample-files/tpp2.cnf)
-
-Then execute the following commands to generate the required certificates:
-
-```bash
-openssl req -new -newkey rsa:2048 -nodes -out tpp1.csr -keyout tpp1.key -config ./tpp1.cnfopenssl x509 -req -days 3650 -in tpp1.csr -CA ca1.crt -CAkey ca1.key -CAcreateserial -out tpp1.crtopenssl req -new -newkey rsa:2048 -nodes -out tpp2.csr -keyout tpp2.key -config ./tpp2.cnfopenssl x509 -req -days 3650 -in tpp1.csr -CA ca2.crt -CAkey ca2.key -CAcreateserial -out tpp2.crt
-```
-
-### Deploy root CA certificates on the Open Banking platform
-
-#### Cloudentity
-
-Connect to the Cloudentity admin page on `https://Cloudentity./app/default/admin/`.
-
-1. Select workspace **openbanking_brasil**.
-2. Click **Settings** on the left panel.
-![Cloudentity Authorization Settings](/Images/mtls-acp-auth.png)
-3. Click **Authorization** on the main frame.
-4. Scroll down to **Trusted client certificates**.
-![Cloudentity Trusted client certificates ](/Images/mtls-acp-ca.png)
-5. Paste ca1.crt and ca2.crt contents in the text box.
-6. Click **Save**.
-
-#### APIM
-
-The certificate is managed by nginx. It requires that all root CA used for signing client certificates must be in a secret.
-
-The secret name is apitraffic-mtls-rootca in the namespace open-banking-apim.
-
-1. First, concatenate all root CA and encode it in base64.
-
- ```bash
- cat ca1.crt ca2.crt > ca.crtcat ca.crt | base64
- ```
-
-2. Edit the values.yaml file in the open-banking-apim Helm chart. Replace the encoded string on value apitraffic.mtlsRootCa.
-![values.yaml](/Images/mtls-apim-yaml.png)
-
-3. For first installation, use the Helm install command otherwise use the Helm upgrade command.
-
- ```bash
- helm install/upgrade open-banking-apim -n open-banking-apim
- ```
-
-#### NGINX
-
-For upgrades only, nginx needs to be restarted with a rollout restart command to apply the new root CA.
-
-```bash
-kubectl get deployment -n kubectl rollout restart deployment -n
-```
-
-Check that all nginx pods are restarted with the age column using the following command:
-
-```bash
-kubectl get pods -n
-```
-
-## Test the MTLS setup
-
-Here are several scenarios you can use to test the MTLS setup with NGINX and APIM:
-
-* Configure both CA1 and CA2 in NGINX, APIM, and Cloudentity as described in the previous section.
- * Use a simple curl command to test a call without cert and keys.
- * `curl 'https://mtls-api-proxy./healthcheck'`
- * The call should return 400 with a SSL certificate error
- * Use a simple curl command to test sending the cert and key for TPP1 and TPP2.
- * `curl 'https://mtls-api-proxy./healthcheck' --cert tpp1.crt --key tpp1.key`
- * `curl 'https://mtls-api-proxy./healthcheck' --cert tpp2.crt --key tpp2.key`
- * The call should return 200 with status ok
-* Configure only CA1 in NGINX, APIM, and Cloudentity as described in the previous section.
- * Use a simple curl command to test sending the cert and key for TPP2.
- * `curl 'https://mtls-api-proxy./healthcheck' --cert tpp2.crt --key tpp2.key`
- * The call should return 400 with a SSL certificate error
-
-You can do similar tests on Cloudentity using the following curl command:
-
-```bash
-curl --request POST 'https://acp./default/openbanking_brasil/oauth2/token' \
---data-urlencode 'grant_type=client_credentials' --data-urlencode 'scope=accounts' \
---data-urlencode 'client_id=tpp1' --cert tpp1.crt --key tpp1.key
-```
\ No newline at end of file
diff --git a/content/en/docs/Configuration/Certificate Management/server-certificates.md b/content/en/docs/Configuration/Certificate Management/server-certificates.md
deleted file mode 100644
index 407d6a5b..00000000
--- a/content/en/docs/Configuration/Certificate Management/server-certificates.md
+++ /dev/null
@@ -1,105 +0,0 @@
----
-title: "Server certificates"
-linkTitle: "Server certificates"
-description:
-weight: 1
-date: 2021-09-02
----
-
-How to change and test the server certificate configurations used for https services.
-
-## Secure external access to services
-
-Server certificate are required for all of the following ingresses:
-
-| Ingress Name | External address | NAMESPACE |
-|-------------------------------------------|----------------------------------------|--------------------------------|
-| acp | acp.`` | open-banking-cloudentity |
-| apimanager | api-manager.`` | open-banking-apim |
-| gatewaymanager | api-gateway-manager.`` | open-banking-apim |
-| traffic | api.`` | open-banking-apim |
-| traffichttps | services-api.`` | open-banking-apim |
-| trafficmtls | mtls-api-proxy.`` | open-banking-apim |
-| consent-openbanking-consent-admin | consent-admin.`` | open-banking-consent |
-| consent-openbanking-consent-page | consent.`` | open-banking-consent |
-| consent-openbanking-consent-self-service | consent-selfservice.`` | open-banking-consent |
-| jwe-generator | jwe.`` | open-banking-jwe |
-
-These certificates are set at the deployment on each Ingress. See the following options to use your own certificates.
-
-### Use cert-manager
-
-You can configure [cert-manager](https://cert-manager.io/) at the ingress controller level. This tool is recommended to manage all certificates of your cluster from the same component.
-You can configure your issuers, assignment rules, and so on. Refer to for more details.
-
-See this tutorial on how to configure cert-manager a Kubertnetes cluster using Let's Encrypt: .
-
-### Use a wildcard certificate
-
-If you have a wildcard certificate matching `*.`, it can be configured for all ingress listed above. This certificate should be declared for each Helm chart deployment where you have an ingress defined. You can do so during the first deployment, or update it later if you change certificate strategy or if you need to renew the certificate.
-
-For each Helm chart where you have a record for global.ingress.wildcard in the `values.yaml`, set its value to `true` and update the global.ingress.certmanager, global.ingress.cert and global.ingress.key values as follows:
-
-```yaml
-global:
- ingress:
- certManager: false
- wildcard: true
- cert: |
- -----BEGIN CERTIFICATE-----
- <>
- -----END CERTIFICATE-----
- -----BEGIN CERTIFICATE-----
- <>
- -----END CERTIFICATE-----
- -----BEGIN CERTIFICATE-----
- <>
- -----END CERTIFICATE-----
-
- key: |
- -----BEGIN RSA PRIVATE KEY-----
- <>
- -----END RSA PRIVATE KEY-----
-
-```
-
-If a Helm chart has ingress but does not have the global.ingress.wildcard option, simply refer to [use specific certificates](#use-specific-certificates) below to set the wildcard certificate in the appropriate record.
-
-### Use specific certificates
-
-If you have a specific certificate matching each external address listed above, you can configure each of them in each solution component. This certificate should be declared for each Helm chart deployment where you have an ingress defined. You can update it during the first deployment, or update it later if you change the certificate strategy or if you need to renew the certificate.
-
-For each Helm chart, update every certmanager, cert, and key values in the `values.yaml` as follows in you have an ingress component:
-
-```yaml
-global:
- ingress:
- certManager: false
- wildcard: false #only if it exists
-: #do this for each component with ingress values as below
- ingress:
- cert:
- -----BEGIN CERTIFICATE-----
- <>
- -----END CERTIFICATE-----
- -----BEGIN CERTIFICATE-----
- <>
- -----END CERTIFICATE-----
- -----BEGIN CERTIFICATE-----
- <>
- -----END CERTIFICATE-----
-
- key: |
- -----BEGIN RSA PRIVATE KEY-----
- <>
- -----END RSA PRIVATE KEY-----
-
-```
-
-{{% alert title="Important" color="warning" %}}Make sure to keep the indent and format similar as above, as well as the empty line after certificate and key.{{% /alert %}}
-
-
\ No newline at end of file
diff --git a/content/en/docs/Configuration/_index.md b/content/en/docs/Configuration/_index.md
index 6285946f..ad89ab33 100644
--- a/content/en/docs/Configuration/_index.md
+++ b/content/en/docs/Configuration/_index.md
@@ -6,4 +6,4 @@ weight: 5
This section provides configuration guidelines for Amplify Open Banking.
-Please click on a link below for more information.
\ No newline at end of file
+Please click on a link below for more information.
diff --git a/content/en/docs/Configuration/ampint-environment-properties.md b/content/en/docs/Configuration/ampint-environment-properties.md
new file mode 100644
index 00000000..f5e69e19
--- /dev/null
+++ b/content/en/docs/Configuration/ampint-environment-properties.md
@@ -0,0 +1,78 @@
+---
+title: "Amplify Integration"
+linkTitle: "Amplify Integration"
+weight: 4
+date: 2024-09-10
+---
+
+Open Banking APIs and workflows are developed and exposed via Amplify Integration. These APIs and workflows rely on specific environment properties that must be configured for them to function correctly. This section provides instructions on how to update these environment properties, along with detailed explanations for each property.
+
+{{% alert title="Note" color="primary" %}} For more information on Amplify Integration, refer to the [Axway Documentation Portal](https://docs.axway.com/bundle/amplify_integration/page/amplify_integration_guide.html).{{% /alert %}}
+
+## Steps to configure environment properties
+
+The following steps provide details on how to set up these properties.
+
+1. Log in to Amplify Integration.
+
+2. Navigate to *Manager > Environments*.
+![Go to Environments](/Images/AI-Manager-Environments.png)
+
+3. Click **Details**.
+![View Details](/Images/AI-Env-Property-Details.png)
+
+4. Here you can update the environment properties. The details of the properties to be updated are provided in the next section.
+![Update Properties](/Images/AI-Update-Environment-Properties.png)
+
+## Environment properties
+
+The following environment properties must be set up in each customer's data plane.
+
+| Environment Property Name | Description |
+|--------------------------------------------------------------------------|--------------|
+| Connections_APIFrontendUrl | URL to access the FDX APIs Example:`https://griffin-design.openbanking.example.net:4443/` |
+| Connections_realmName | Realm Name in the authorization server representing customer tenant Example: griffin-design |
+| FDX_Accounts_Search_basePath | Basepath of the FDX Accounts API Default: /fdx/v6/core/accounts |
+| FDX_Authorization_consentDurationOneTimePeriod | Default duration value (in days) for ONE_TIME consent Default: 1 |
+| FDX_Authorization_consentDurationPersistentPeriod | Default long time duration of PERSISTENT consent Default: 36525 |
+| FDX_Authorization_consentDurationSupportedTypes | Supported duration types of consent Default: TIME_BOUND,ONE_TIME,PERSISTENT |
+| FDX_Authorization_consentDurationTimeBoundMax | Maximum allowed duration period (in days) for TIME_BOUND consent Default: 365 |
+| FDX_Authorization_consentDurationTimeBoundMin | Minimum allowed duration period (in days) for TIME_BOUND consent Default: 5 |
+| FDX_Authorization_consentLookbackPeriodMax | Maximum allowed lookback period (in days) for which historical data may be requested; measured from request time, not grant time Default: 90 |
+| FDX_Authorization_consentLookbackPeriodMin | Minimum allowed lookback period (in days) for which historical data may be requested; measured from request time, not grant time Default: 1 |
+| FDX_Authorization_consentSupportedDataClusters | Supported enumerations or types of the clusters of data elements that can be requested in a consent grant Default: ACCOUNT_BASIC,ACCOUNT_DETAILED,TRANSACTIONS,STATEMENTS,CUSTOMER_CONTACT,CUSTOMER_PERSONAL,INVESTMENTS,PAYMENT_SUPPORT |
+| FDX_Authorization_consentSupportedResourceTypes | Types of resources that can be requested and for which consent can be given Default: ACCOUNT |
+| FDX_Authorization_wellKnownNotSupportedKeys | The keys of a well known URI's response coming from the authorization server that need to be suppressed before sending the response Default: introspection_endpoint,userinfo_endpoint,end_session_endpoint,check_session_iframe,device_authorization_endpoint,backchannel_authentication_endpoint,registration_endpoint |
+| FDX_Kafka_Publish_Notification_priority | Priority level of the logged events Default: MEDIUM |
+| FDX_Kafka_Publish_Notification_severity | Severity level of the logged events Default: INFO |
+| FDX_Kafka_Publish_Notification_tenantType | Type of the tenant Default: DATA_PROVIDER |
+| FDX_Notification_Subscription_eventTypes | Supported event types for subscription Default: CONSENT_PARTIALLY_AUTHORIZED,CONSENT_AUTHORIZED,CONSENT_REJECTED,CONSENT_ON_HOLD,CONSENT_CONSUMED,CONSENT_EXPIRED,CONSENT_MODIFIED |
+| Generic_Authorization_loginUrl | Login url of the authorization server Example: `https://auth.openbanking.example.net/realms/griffin-design/protocol/openid-connect/auth`|
+| Generic_Authorization_maxConsentAllowedPerUserPerPartner | Maximum number of allowed consents per user per partner Default: 10 |
+| Generic_Authorization_scaMethodEnabled | If strong customer authentication is enabled Default: TRUE |
+| Generic_Authorization_scaMethodExplanation | Description of the SCA method used |
+| Generic_Authorization_scaMethodName | SCA method name Default: Keycloak Redirection |
+| Generic_Authorization_scaMethodProtocol | SCA method protocol Default: REDIRECT |
+| Generic_Authorization_scaMethodRedirectUrl | SCA method redirect URL Example: `https://auth.openbanking.example.net/realms/griffin-design/protocol/openid-connect/auth` |
+| PartnerCoreService_CacheExpirationInMinutes | Cache expiration time in minutes Default: 10 |
+| PartnerCoreService_OnboardingFieldLabel_consentDataClusters | Field from the onboarding portal that maps to data clusters Default: Scope |
+| PartnerCoreService_OnboardingFieldLabel_consentDurationPeriod | Field from the partner onboarding portal that maps to consent duration period Default: Duration Period |
+| PartnerCoreService_OnboardingFieldLabel_consentDurationType | Field from the onboarding portal that maps to consent duration type Default: Duration Type |
+| PartnerCoreService_OnboardingFieldLabel_consentLookbackPeriod | Field from the onboarding portal that maps to consent lookback period Default: Lookback Period |
+| PartnerCoreService_OnboardingFieldLabel_intermediaryHomeUrl | Field from the onboarding portal that maps to intermediary uri Default: Intermediary URI |
+| PartnerCoreService_OnboardingFieldLabel_intermediaryLogoUrl | Field from the onboarding portal that maps to intermediary logo uri Default: Intermediary Logo URI |
+| PartnerCoreService_OnboardingFieldLabel_intermediaryme | Field from the onboarding portal that maps to intermediary name Default: Intermediary Name |
+| PartnerCoreService_OnboardingFieldLabel_intermediaryRegisteredEntityId | Field from the onboarding portal that maps to intermediary registered entity id Default: Intermediary Registered Entity Id |
+| PartnerCoreService_OnboardingFieldLabel_intermediaryRegisteredEntityName | Field from the onboarding portal that maps to intermediary registered entity name Default: Intermediary Registered Entity Name |
+| PartnerCoreService_OnboardingFieldLabel_intermediaryRegistry | Field from the onboarding portal that maps to intermediary registry Default: Intermediary Registry |
+| PartnerCoreService_OnboardingFieldLabel_partnerHomeUrl | Field from the onboarding portal that maps to partner home url Default: Website |
+| PartnerCoreService_OnboardingFieldLabel_partnerLogoUrl | Field from the onboarding portal that maps to logo uri Default: Logo URI |
+| PartnerCoreService_OnboardingFieldLabel_partnerRegisteredEntityId | Field from the onboarding portal that maps to partner registered entity id Default: Registered Entity Id |
+| PartnerCoreService_OnboardingFieldLabel_partnerRegisteredEntityName | Field from the onboarding portal that maps to registered entity name Default: Registered Entity Name |
+| PartnerCoreService_OnboardingFieldLabel_partnerRegistry | Field from the onboarding portal that maps to partner registry Default: Registry |
+| PartnerCoreService_OnboardingFieldLabel_partnerType | Field from the onboarding portal that maps to partner type Default: Entity Type |
+| defaultPageSize | Default number of records in a single page Default: 10 |
+| maxPageSize | Maximum allowed number of records in a single page Default: 100 |
+| organizationId | Organization identifier of the customer from market place |
+| organizationName | Organization name of the customer from market place |
+| revokeRefeshTokenOnConsentExpiry | If refresh token needs to be revoked if consent expires Default: TRUE |
diff --git a/content/en/docs/Configuration/api-management.md b/content/en/docs/Configuration/api-management.md
deleted file mode 100644
index 197f951a..00000000
--- a/content/en/docs/Configuration/api-management.md
+++ /dev/null
@@ -1,127 +0,0 @@
----
-title: "API Management Configuration"
-linkTitle: "API Management"
-weight: 1
-date: 2021-09-02
----
-
-## API Gateway
-
-Amplify Open Banking API Gateway is based on the Axway API Gateway product.
-
-Most features are documented in the [Axway API Gateway documentation](https://docs.axway.com/bundle/axway-open-docs/page/docs/apim_administration/apigtw_admin/index.html).
-
-### Key Properties Store (KPS) configuration
-
-The Key Properties Store of API Gateway is used to store the solution configuration variables.
-This configuration can be read at the beginning of any policy using a common policy "Read Configuration."
-
-| Column Name | Type | Purpose |
-| --- | --- | --- |
-| a_id | java.lang.String | Autogenerated Id. |
-| b_tenantId | java.lang.String | Bank Identifier (helpful in multi tenant setup). |
-| c_name | java.lang.String | API Name. |
-| d_version | java.lang.String | API Version. |
-| e_method | java.lang.String | API Method. |
-| f_extension_1 | java.lang.String | For future use |
-| g_extension_2 | java.lang.String | For future use. |
-| k_values | java.util.Map`` | Key Value Pairs help in extending configuration whenever we want without deployment. New key value pairs can be added easily.|
-
-In FDX deployment, by default, there is at least one row for each API and a row with generic information which is applicable to all APIs.
-
-In Open Finance Brazil deployment, by default, only one line exists with no criteria (columns b to e) and values (column k) corresponding to solution deployment parameters.
-
-Refer to [Solution Deployment](/docs/deployment/installation) to see how to change these values during deployment.
-
-Additionally, you can check and update your current configuration from API Gateway Manager - Settings - Key Property Stores.
-
-![kps-configuration](/Images/api-gateway-manager-kps-configuration.png)
-
-Click on configuration and the line to be checked or updated.
-
-![kps-values](/Images/api-gateway-manager-kps-values.png)
-
-Several values should correspond to the settings of Cloudentity or its consent module. See the below mapping table to check that the KPS values are correct.
-
-#### Mapping table for FDX
-
-| KPS Values | How to retrieve or check this values in Cloudentity UI |
-| --- | --- |
-| oauth_ce_host | hostname of Cloudentity server |
-| oauth_ce_port | port of Cloudentity server |
-| oauth_ce_tenantid | tenant id in Cloudentity server |
-| oauth_ce_id | workspace id in Cloudentity where client applications are created and consents are stored |
-| oauth_introspect_client_id | client id of app named "bank" in FDX workspace |
-| oauth_ce_idp_clientId | client id of the custom IdP configured in FDX workspace |
-| oauth_ce_idp_clientSecret | client secret of the custom IdP configured in FDX workspace |
-| oauth_consent_user_clientSecret | client secret of the custom IdP configured in bank-customers workspace |
-
-#### Mapping table for Open Finance Brazil
-
-| KPS Values | How to retrieve or check this values in Cloudentity UI |
-| --- | --- |
-| oauth_consent_clientId | Custom IDP Demo bank login ID: bank customer. |
-| oauth_consent_clientSecret | Custom IDP Demo bank login secret: bank customer. |
-| oauth_consent_confirmation_clientid | Settings: consent screen client id. |
-| oauth_consent_confirmation_clientSecret | Settings: consent screen client secret. |
-| oauth_consent_user_clientSecret | Custom IDP Demo bank login secret: open banking workspace. |
-| oauth_host | Host of Cloudentity server. |
-| oauth_id | Openbanking workspace id in Cloudentity server. |
-| oauth_introspect_clientid | App is bank in openbanking workspace. |
-| oauth_tenantid | Tenant id in Cloudentity server. |
-
-### API policies
-
-API Gateway is configured with several API policies that are used with Open Banking flows.
-You may want to customize some of these policies.
-
-You can check the following policy definitions by opening Policy Studio and navigating to Policies.
-
-For FDX deployment policy container name is - #AMPLIFY-OB-FDX.
-
-For Open Finance Brazil deployment policy container name is - #AMPLIFY-OB.
-
-![apim-policy-studio-apis](/Images/apim-policy-studio-api-containers.png)
-
-If you decide to change one of them, you can use Policy Studio directly for the development environment only.
-
-For other environments, you must update the FDX-YAML policy project, which is part of apigateway-config-fdx-7.7.0.20xxxxxx-BNxx.tar.gz, and deploy the configuration as detailed in [Mount the FDX Configuration](/docs/deployment/installation/api-management/fdx-apim/#mount-the-fdx-configuration).
-
-{{% alert title="Note" color="primary" %}} If you make changes to any of the policies in this container then those changes will be overridden by future upgrades. {{% /alert %}}
-
-### Certificates
-
-API Gateway is configured with several certificates that are used during the runtime:
-
-* Server certificate
-* Client certificate authority
-* Jwt certificate
-* Keys
-
-You can check which ones are in use by opening Policy Studio and navigating to Environment Configuration - Certificate and Keys - Certificates.
-Right-click a certificate to see if there are any references to it, meaning that they are currently in use.
-
-![apim-policy-studio-certificates](/Images/apim-policy-studio-certificates.png)
-
-If you identify the need to change one of them, refer to the API Gateway instructions that you can find under each section of [Certificate Management](/docs/configuration/certificate-management).
-
-## API Manager
-
-Configure the Open Banking API Manager settings, APIs and organizations and applications.
-
-Amplify Open Banking API Manager is based on the Axway API Manager product. Most features are documented in the [Axway API Manager documentation](https://docs.axway.com/bundle/axway-open-docs/page/docs/apim_administration/apimgr_admin/index.html).
-
-
-
-### API Management
-
-Upon solution deployment, several Open Banking APIs are deployed and published in the catalog.
-You can use the admin interface to update the APIs.
-
-![open banking apis](/Images/api-manager-apis.png)
-
-Refer to the details in the [Axway API Manager documentation](https://docs.axway.com/bundle/axway-open-docs/page/docs/apim_administration/apimgr_admin/api_mgmt_virtualize_web/index.html) to manage API details.
diff --git a/content/en/docs/Configuration/auth-server-config.md b/content/en/docs/Configuration/auth-server-config.md
new file mode 100644
index 00000000..f5095698
--- /dev/null
+++ b/content/en/docs/Configuration/auth-server-config.md
@@ -0,0 +1,103 @@
+---
+title: "Authorization Server"
+linkTitle: "Authorization Server"
+weight: 6
+date: 2024-09-10
+---
+
+This section describes the necessary configuration settings for the Authorization Server, which is a critical component of the Open Banking solution. Proper configuration of the Authorization Server ensures secure and compliant access to APIs, enabling robust authentication and authorization processes. This guide will walk you through the key configuration steps and parameters required to align the Authorization Server with the overall solution architecture.
+
+## IdP configuration
+
+Integrating an Identity Provider (IdP) is essential for managing user authentication within the Open Banking solution. This section outlines the steps required to configure and integrate the IdP with the Authorization Server, enabling seamless and secure authentication processes. By connecting the Authorization Server to your chosen IdP, you can leverage existing user directories, enforce authentication policies, and streamline the overall login experience for users.
+
+The following steps detail how to configure your identity provider.
+
+1. Log in to Authorization Server.
+2. Select *Identity providers* on the left menu. Select **OpenId Connect v1.0** from the Add provider menu.
+ ![Identity providers](/Images/AS-IdPs.png)
+3. Create a new Alias and provide a valid Discovery endpoint. This is the "well-known" URL of the external IdP provider. Also provide the Client ID and Client Secret of the external IdP.
+ ![Select OpenID Connect](/Images/AS-Configure-IdP.png)
+4. Click **Add** to save the configuration.
+5. Open the newly created IdP.
+6. Open the *Mapper* tab and create a userIdMapper in the IdP. Select Mapper type **User Session Note Mapper**. Make sure you are using the correct claim in userId mapper.
+ ![Create user mapper](/Images/AS-IdP-User-Mapper.png)
+
+The external IdP integration is completed.
+
+## Client policies update
+
+The following steps detail how to update the client policies.
+
+1. Select *Realm settings* on the left menu after selecting the desired realm.
+2. Open the *Client Policies* tab.
+ ![Client Policies](/Images/client-policies.png)
+3. Select **ob-issuer-verification** from the policies section.
+4. Select **ob-issuer** Executor type.
+5. Update the issuer URL to the authorize endpoint. This endpoint should be available in the tenant environment. (Shared Dataplane for Design and Check)
+ ![OB Issuer](/Images/ob-issuer.png)
+
+The policy issuer update is completed.
+
+## Token mapper configuration
+
+The following steps detail how to update the token mapper.
+
+1. Select *Client scopes* on the left menu after selecting the desired customer realm.
+![Client Scopes](/Images/client-scopes.png)
+2. Search for "fdx-resource" mapper in the search box.
+3. Click on the mappers and open the *Mappers* tab.
+![FDX Resurce ](/Images/fdx-resource.png)
+4. Open **Openbanking Issuer Mapper**, update the Issuer claim with the authorize endpoint that will be used for Design and Check mode, present in the customer tenant.
+![Issuer Mapper ](/Images/mapper.png)
+5. Save the mapper.
+
+The token mapper issuer update is completed.
+
+## Authentication configuration
+
+Authentication is the area where you can configure and manage different credential types, authentication flows, screens, and actions during log in, registration, and other Keycloak workflows.
+
+The following steps detail how to create the post-login flow in addition to the built-in flows that are already there.
+
+1. Select *Authentication* on the left menu after selecting the desired realm.
+2. Configure the **post-login-flow** - This specifies the actions needed after the authentication of the user is done successfully.
+ ![Post login flow](/Images/post-login-flow.png)
+
+* **END USER UPDATE** authenticator - When the user is successfully authenticated, Keycloak stores the id_token claims in the user session attribute. This is configured in the END USER UPDATE authenticator. The following configurations must be set for END USER UPDATE.
+
+| Configuration | Required | Default Value | Description |
+| ------------------------------|----------|---------------|------------------------------------------------------------------------------------------------------------------------------------------------|
+| Internal Resource Update Host | true | null | This is the host URL for resource update API. End-User Update SPI will use this host URI to update end-user information in the cosnet resource. |
+| Internal Client Id | true | internal | The internal client Id to fetch auth token using client-credentials flow. |
+| Auth Server Host | true | null | This is Auth-Token host. Using this host, End-User Update SPI will fetch the internal token with required scope. |
+| User Id claim | true | sub | This is claim value in which userId is present from the IDP. |
+| Openbanking Realm Name | true | null | Openbanking realm name to fetch internal tokens. |
+
+Refer to the following image:
+
+![END USER UPDATE](/Images/end-user-update.png)
+
+* **CONSENT GRANT REDIRECT** authenticator - This is configured to redirect the user to the consent grant application of the bank. The following configurations must be set for CONSENT GRANT REDIRECT.
+
+| Configuration | Required | Default Value | Description |
+|--------------------------------|----------|---------------|----------------------------------------------------------------------------------------------------------------------------------------|
+| Internal Resource Update Host | true | null | This is host URL for resource update API. The Consent Grant Redirect Update SPI will use this host URI to update account information. |
+| Internal Client Id | true | internal | The Internal Client Id to fetch auth token using client-credentials flow. |
+| Auth Server Host | true | null | This is Auth-Token host. Using this host, End-User Update SPI will fetch the internal token with required scope. |
+| User Id claim | true | sub | This is claim value in which userId is present from the IDP. |
+| Consent Grant Uri | true | null | Provide externally hosted consent grant URL. |
+| Action Token Expiration Period | true | 300 | This period will determine the maximum allowed time (in seconds) for external consent application. |
+| Issuer url | true | null | This issuer URL will be set in the authorization code jwt response. |
+
+Refer to the image below:
+
+![CONSENT GRANT REDIRECT](/Images/consent-grant-redirect.png)
+
+{{< alert title="Note" color="primary" >}}The above authenticators should be in the same sequence. The sequence cannot be changed.{{< /alert >}}
+
+## Update Identity providers configuration
+
+The Identity providers configuration created previously must be updated with the Post login flow, as mentioned in the following image.
+
+![IDP WITH POST LOGIN](/Images/post-login-identity-provider.png)
diff --git a/content/en/docs/Configuration/consent-app-customizations.md b/content/en/docs/Configuration/consent-app-customizations.md
deleted file mode 100644
index f220d7e7..00000000
--- a/content/en/docs/Configuration/consent-app-customizations.md
+++ /dev/null
@@ -1,127 +0,0 @@
----
-title: "Consent Apps Customization"
-linkTitle: "Consent Apps Customization"
-weight: 10
-date: 2021-09-02
----
-This section includes details to customize the Amplify Open Banking Consent Apps.
-
-## Consent page
-
-The Consent page embedded in the solution is provided for demonstration purposes only. Each customer should customize the consent page to match their target application's requirements.
-
-For this you would need to customize the corresponding Docker image and replace its reference to yours.
-
-* Download the [consent-page-image](https://axway-open-banking-docs.netlify.app/sample-files/consent-page-image.zip) Docker project that is the customization kit for the consent page.
-* Customize the items you need to be customized as described in the sections below.
-* Rebuild the Docker image with the custom change, and tag it for your own Docker repository: this Docker repository should be reachable from the Kubernetes cluster.
-
-```console
-docker build consent-page -t /open-banking-consent-page:
-```
-
-* Push the Docker image to your Docker repository.
-
-```console
-docker push /open-banking-consent-page:
-```
-
-* Update the `open-banking-consent/files/consent.values.yaml` used in [Install Open Banking Consent Helm chart](/docs/deployment/installation/cloudentity#install-open-banking-consent-helm-chart) to insert the _image_ record inside the _consentPage_ record as shown below.
-
-```yaml
- consentPage:
- image:
- pullPolicy: IfNotPresent
- repository: /open-banking-consent-page
- tag:
-```
-
-* Upgrade the Helm chart release
-
-```console
-helm upgrade consent -n open-banking-consent cloudentity/openbanking –-version -f open-banking-consent/files/consent.values.yaml
-```
-
-The consent page should now reflect your changes on your Kubernetes environment.
-
-The sections below details how to customize the consent page in the Docker image project.
-
-### Consent page template files
-
-The consent pages are generated based on customizable template files.
-
-You can find them in `consent/consent-page/templates/base`.
-
-![Consent page image files](/Images/consent-page-files.png)
-
-For instance, there are two main files you can customize for payment.
-![obbr-payment-consent-1.tmpl](/Images/consent-page-obbr-payment1.png)
-
-* obbr-payment-consent-1.tmpl
-
-![obbr-payment-consent-2.tmpl](/Images/consent-page-obbr-payment2.png)
-
-* obbr-payment-consent-2.tmpl
-
-### Logo
-
-The logo can be changed by switching the name of the file in the image tag below.
-
-```html
-
-```
-
-Host a new logo in the `consent/consent-page/assets/images` folder, preferably with an SVG extension. The set width of the template is 300px, so there is no need for a bigger file.
-
-### Background color
-
-Access the stylesheet at `consent/consent-page/assets/style.css`.
-![style.css](/Images/consent-page-css.png)
-
-Change the background-color of the root element.
-
-### Text translations
-
-All text elements can be translated using the file in the `consent/consent-page/templates/translations/en-us.yaml` folder.
-
-Open the file and scroll the page until you find the syntax "br.payment..."; this syntax represents the files of the consent-page.
-
-![en-us.yaml](/Images/consent-page-language.png)
-
-Translate all texts for the desired messages in the target language.
-
-### Button colors
-
-Cancel and confirm buttons are located and styled inline in the consent-page files.
-
-```html
-
-```
-
-Change the colors, widths, shapes, borders, and paddings as you like.
-
-### Payment type choice
-
-As of the date of this document the only payment type accepted is PIX, so there is no need for a dropdown.
-Change the Payment Method of file `obbr-payment-consent-1.tmpl` from a `` tag to a paragraph (`PIX
`) explicitly saying PIX.
-
-### Account list
-
-All accounts owned by the user from the bank need to be shown at the Payment Account dropdown as options for the user to select or displayed as a set of cards.
-
-### Account balance
-
-If accessible, it is considered a best practice to present the account balance under the payment amount in the `obbr-payment-consent-2.tmpl` file.
-
-![payment-amount](/Images/consent-page-payment-amount.png)
diff --git a/content/en/docs/Overview/Integration/Financial-Data-Exchange-Integration/_index.md b/content/en/docs/Overview/Integration/Financial-Data-Exchange-Integration/_index.md
index d4ff3767..ce80d89e 100644
--- a/content/en/docs/Overview/Integration/Financial-Data-Exchange-Integration/_index.md
+++ b/content/en/docs/Overview/Integration/Financial-Data-Exchange-Integration/_index.md
@@ -17,7 +17,7 @@ The flow is summarized as follows:
All APIs that provide access to data are implemented in the same manner. The consent/data access pattern relating to Account Information is therefore representative regardless of the specific resource (checking accounts, credit cards, loans, and so on).
-![FDX Wrokflow](/Images/FDX_Workflow_0.png)
+![FDX Wrokflow](/Images/FDX-Workflow.svg)
### Steps
@@ -37,15 +37,14 @@ Step 2: DR initiates a POST request to Data Providers’s (DP) POST /par endpoin
{
"type": "fdx_v1.0",
"consentRequest": {
- "durationType": "ONETIME",
+ "durationType": "ONE_TIME",
"lookbackPeriod": 60,
"resources": [
{
"resourceType": "ACCOUNT",
"dataClusters": [
"ACCOUNT_DETAILED",
- "TRANSACTIONS",
- "STATEMENTS"
+ "TRANSACTIONS"
]
}
]
diff --git a/content/en/docs/Overview/Integration/Open-Finance-Brazil-Integration/_index.md b/content/en/docs/Overview/Integration/Open-Finance-Brazil-Integration/_index.md
deleted file mode 100644
index baea52b3..00000000
--- a/content/en/docs/Overview/Integration/Open-Finance-Brazil-Integration/_index.md
+++ /dev/null
@@ -1,20 +0,0 @@
----
-title: "Open Finance Brazil End to End Journey"
-linkTitle: "Open Finance Brazil End to End Journey"
-weight: 7
-date: 2023-03-15
----
-
-This end-to-end flow provides a means to show how individual components are used in Amplify Open Banking.
-
-The flow is summarized as follows:
-
-* The Data Recipient (DR) obtains Consent from the Customer to access their data or make payments on their behalf at a given bank.
-* The DR creates ("lodges") Consent at the target bank and redirects the Customer to the bank.
-* The Customer authenticates themselves using their online banking credentials and confirms the Consent is correct.
-* With Consent confirmed the Customer is redirected back to the DR who then gets an Access Token.
-* The DR can then retrieve data or initiate payment on behalf of the Customer.
-
-All APIs that provide access to data are implemented in the same manner. The consent/data access pattern relating to Account Information is therefore representative regardless of the specific resource (checking accounts, credit cards, loans, and so on).
-
-![End-to-end web journey sequence](/Images/Generic_Web_Journey_Sequence.svg)
\ No newline at end of file
diff --git a/content/en/docs/Overview/Integration/_index.md b/content/en/docs/Overview/Integration/_index.md
index 212173d0..4faeea9a 100644
--- a/content/en/docs/Overview/Integration/_index.md
+++ b/content/en/docs/Overview/Integration/_index.md
@@ -9,24 +9,26 @@ The diagram below shows a high-level integration view of the Amplify Open Bankin
The aim of this diagram is to provide an initial understanding of the integration between components.
-![Integration Overview](/Images/Integration_Overview_0.svg)
+![Integration Overview](/Images/Integration-Overview.svg)
Refer to the table for an explanation of each labeled arrow in the diagram.
| # | Description |
| --: | ----------- |
-| 1 | A Data Recipient Developer uses the Marketplace to enroll themselves or their organization. |
-| 2 | The Marketplace communicates with the Discovery Agent to provision applications and associated credentials. |
-| 3 | The Discovery Agent in turn registers those credentials in the Identity Management solution. |
-| 4 | With the application registered the Data Recipient developer uses the Development Tools to engineer and deploy their application. A Consumer uses that application for specific purposes, but is required to provide consent to the Data Recipient App. |
-| 5 | To provide Consent the Data Recipient App contacts the Identity Management service to start the OpenID Connect Hybrid Flow. Identity Management to verify the Data Recipient App credentials and return a redirection to the appropriate login screens. |
-| 6 | The Data Recipient App redirects the user to Identity Management or the Bank Identity Provider depending on the deployment approach. |
-| 7 | The Consumer logs in and provides confirm of consent to the Data Recipient App. |
-| 8 | With Consent approved and an appropriate Authorization Code the Data Recipient obtains an Access Token and retrieves data on behalf of the Consumer. |
-| 9 | The API Gateway connects with Identity Management to do the token and consent introspection |
-| 10 | The API Gateway and integration applications retrieves data from the appropriate data source. This can either be from Core Banking Applications or Mock Data provided with the Amplify Open Banking solution. |
-| 11 | The events are logged to the Amplify Platform for Analytics. |
+| 1 | A Data Recipient Developer uses the Marketplace to enroll themselves or their organization.
+| 2 | The Marketplace communicates with the Discovery Agent to provision applications and associated credentials.
+| 3 | The Discovery Agent in turn registers those credentials in the Authorization Server.
+| 4 | With the application registered, the Data Recipient Developer engineer deploys their application. A Consumer uses that application for specific purposes but is required to provide consent to the Data Recipient App.
+| 5 | To provide Consent, the Data Recipient App contacts the Authorization Server to start the OpenID Connect Hybrid Flow. Authorization Server verifies the Data Recipient App credentials and returns a redirection to the appropriate login screens.
+| 6 | The Data Recipient App redirects the user to the Bank Identity Provider.
+| 7 | The Consumer completes the login.
+| 8 | The consumer provides the confirmation of consent.
+| 9 | With Consent approved and an appropriate Authorization Code, the Data Recipient obtains an Access Token and retrieves data on behalf of the Consumer.
+| 10 | The API Gateway connects with the Authorization Server to do the token introspection.
+| 11 | The API Gateway retrieves data from the appropriate data source via Bank Connectors. This can be from Core Banking Applications.
+| 12 | The events are logged to the Amplify Platform for Analytics.
+| 13 | To provide Analytics to consumers, Marketplace connects with Amplify Platform and fetches events.
The sections below expand on this through several more detailed sequence-based views.
-Note these sequence diagrams **focus largely on the happy path** and do not show specific error flows for the sake of brevity.
\ No newline at end of file
+{{% alert title="Note" color="primary" %}} These sequence diagrams **focus largely on the happy path** and do not show specific error flows for the sake of brevity.{{% /alert %}}
diff --git a/content/en/docs/Overview/Integration/applying-consent.md b/content/en/docs/Overview/Integration/applying-consent.md
index ddfc106f..4444cee2 100644
--- a/content/en/docs/Overview/Integration/applying-consent.md
+++ b/content/en/docs/Overview/Integration/applying-consent.md
@@ -11,10 +11,10 @@ Access controls need to be applied based on the customer consent to return only
This shows the approach based on retrieving account information. The preferred implementation is summarized as follows:
* A Data Recipient requests a given resource. If the Data Recipient does not have consent to access that resource on behalf of an End User the request is immediately rejected.
-* The request is augmented with details of the consented accounts and permissions and forwarded to the backend integration application.
-* The backend integration application calls the backend systems using appropriate transport and arguments.
+* The request is augmented with details of the consented accounts and permissions and forwarded to the core banking connector.
+* The core banking connector calls the backend systems using appropriate transport and arguments.
* The backend retrieves the appropriate data, filtered for permitted accounts. Permissions are then applied to remove any data clusters that a customer has not consented to share.
-* The data is then returned to the backend integration application which formats the response to the required standard.
+* The data is then returned to the core banking connector which formats the response to the required standard.
* In turn the response is returned to the Data Recipient App by the API Gateway.
For optimal performance, filtering data based on the customer should be executed **as close to the data as possible**. This therefore requires customers to implement this at the source of data.
diff --git a/content/en/docs/Overview/Integration/payment-initiation-ciba.md b/content/en/docs/Overview/Integration/payment-initiation-ciba.md
index 8136b4db..64f16a06 100644
--- a/content/en/docs/Overview/Integration/payment-initiation-ciba.md
+++ b/content/en/docs/Overview/Integration/payment-initiation-ciba.md
@@ -1,4 +1,4 @@
----
+
diff --git a/content/en/docs/Overview/Technical/_index.md b/content/en/docs/Overview/Technical/_index.md
deleted file mode 100644
index c12aee0f..00000000
--- a/content/en/docs/Overview/Technical/_index.md
+++ /dev/null
@@ -1,23 +0,0 @@
----
-title: "Technical Architecture"
-linkTitle: "Technical Architecture"
-weight: 3
-date: 2021-06-30
----
-
-Amplify Open Banking is designed with flexibility in mind. It therefore has been engineered with as few constraints as possible in terms of deployment approach.
-
-Customers can choose to install the solution either on-premises or in the cloud because the solution is built with a vanilla Kubernetes. This allows customers to make a choice about their target Kubernetes distribution and additional components.
-
-{{% alert title="Note" color="primary" %}} There are required features and security constraints that customers must adhere to. For example, some ingress controllers cannot meet solution's requirements.{{% /alert %}}
-
-## Considerations
-
-The following should be noted when reading the Technical Architecture pages:
-
-* This describes a standard deployment that is the starting point for all installations on a customer's infrastructure.
-* The architecture described is production ready and designed to be highly-available.
-* This architecture can be adapted based on customer requirements, for example:
- * Replacing the nginx ingress controller with an alternative
- * Using their choice of monitoring tools
-* Customers will make their own choice of database-hosting based on what best suits their requirements. For additional information refer to [Google's considerations for databases on Kubernetes](https://cloud.google.com/blog/products/databases/to-run-or-not-to-run-a-database-on-kubernetes-what-to-consider).
\ No newline at end of file
diff --git a/content/en/docs/Overview/Technical/component.md b/content/en/docs/Overview/Technical/component.md
deleted file mode 100644
index d685c488..00000000
--- a/content/en/docs/Overview/Technical/component.md
+++ /dev/null
@@ -1,40 +0,0 @@
----
-title: "Component View"
-linkTitle: "Component View"
-weight: 1
-date: 2021-06-30
----
-
-The diagram below shows a component view of the Amplify Open Banking solution.
-
-![Component View](/Images/Component_View_v320.svg)
-
-The table below provides details of each of the components listed above. The list includes the name of the solution building block to which the component relates.
-
-| Name | Solution Building Block | Purpose | Production Requirement | Notes |
-| ---- | ----------------------- | ------- | ---------------------- | ----- |
-| Ingress Controller | Utilities | Provides the [means for an Ingress resource](https://kubernetes.io/docs/concepts/services-networking/ingress-controllers/) to operate in the Kubernetes environment. Responsible for terminating a mutually-authenticated TLS connection from a client application. This is implemented only on a specific ingress (identity and one API traffic listener m-api.domain-name). | Conditional | Customers can make a choice of Ingress Controller but it must be capable of terminating a mutually-authenticated TLS connection. The Ingress Controller must also be capable of forwarding the certificate fingerprint as an HTTP header to the API Management or Cloudentity. The NGINX Ingress Controller used in the standard deployment is not included in our deployment package. |
-| descheduler | Utilities | The descheduler pod is required to force Kubernetes to allocate pods between different pods after downscaling as Kubernetes does not respect the anti-affinity pod when it downscales the number of replicas. If a descheduler is not used multiple api-traffic pods can be allocated on the same node and result in degraded performance. | Mandatory | This component is not included in our deployment package. |
-| cert-manager | Utilities | Used to generate and renew certificates from a CA and create DNZ zone records. Certificates are created for both ingress and TBC. | Conditional | This component cannot be used as intended for DNS record creation when the Kubernetes cluster is deployed behind other components. This component is not included in our deployment package.|
-| external-dns | Utilities | Used to configure external DNS records for ingress. | Conditional | This component is not required if DNS configuration through cert-manager is not enabled. Customers must use one of the supported providers listed in the [ExternalDNS project](https://github.com/kubernetes-sigs/external-dns). This component is not included in our deployment package.|
-| fluentd | Utilities | Streams all standard output from containers to log store. | Conditional | This component can be replaced by any tool with equivalent capabilities. It is not included in our deployment package. |
-| Grafana | Utilities | Grafana is a tool that displays dashboard information from data sources in the Kubernetes stack. The information includes resources consumption, pod health checks, and so on. | Conditional | This component can be replaced by any tool with equivalent capabilities. It is not included in our deployment package. |
-| Prometheus | Utilities | Monitoring tool for Kubernetes. | Conditional | This component can be replaced by any tool with equivalent capabilities. It is not included in our deployment package. |
-| Admin Node Manager | API Management | | Mandatory | |
-| API Manager | API Management | Management tool for API Management infrastructure. | Mandatory | |
-| API Traffic | API Management | Responsible for receiving and executing all requests from API consumers. | Mandatory | We recommend adapting the minimum sizing according to the estimated volumes per month. This will allow the pod autoscaler to adapt the number of pods during the peak load. To support peak load and SLAs multiple replicas must be used. In addition, the Horizontal Pod Autoscaler (HPA) must be activated (by default this is disabled). The configuration of this component ensures each replica is spread across different nodes (anti-affinity node), which reduces IOPS. These pods require multiple services and ingress as they have multiple listeners.
-| APIMCLI | API Management | Job that configures all API objects in the API Manager including users, settings, APIs, organizations, applications and so on. | Mandatory | This job is executed after each upgrade to ensure the API Manager is up-to-date. All configurations are externalized in a Kubernetes config map to allow the API configuration to be updated by the installer as required. API descriptions in both US English and Portuguese (for Brazil deployments) are available by default. |
-| Cassandra | API Management | Data store for API Manager configuration, throttling, and additional data. | Mandatory | 3 nodes are required in production that must be spread on different availability zones. Supports Cassandra 3.11.11 only and blocks usage of managed databases in all cloud providers. |
-| Discovery Agent | Amplify Agents | Discovery Agent discovers the API from API Manager and makes it available in Amplify | Mandatory | |
-| Traceability Agent | Amplify Agents | Traceability Agent uses the API Gateway events to extract the transaction information and send it to the Amplify platform Observability module | Mandatory | |
-| open-banking-backend (multiple applications) | API Builder | The purpose of these applications is:Provide a mock backend for use in your developer experience if you want.| Conditional | The backend services provided by the open-banking-backend component are created using API Builder and are designed to be reconfigured for use with your backend services to provide the data required for Open Banking. You can swap these out for an application with equivalent functionality if you want. However, if this course of action is taken then the benefit of providing an application that is designed to be compliant with the relevant standards/OpenAPI specification is lost. |
-| MySQL Backend Services | Utilities | Provides storage for mock backend services. | Conditional | Provides storage for backend services where the API Builder applications are using the default configuration. This does not need to be deployed if the backend services APIs are integrated with the Core Banking Applications. |
-| Cloudentity | Identity Management Consent Management | Cloudentity that provides:Authorization Server Token endpoint Management and configuration UI | Mandatory | Cloudentity is required to provide:Compliance with the Brazil FAPI Security Profile. Integration with Consent Management to support Open Banking Brazil standards. Integration with external IDPs already implemented by customers. |
-| acp-cockroachdb-init | Identity Management Consent Management | Job to initialize the default configuration for Cloudentity. | Mandatory | |
-| CockroachDB | Identity Management Consent Management | Cloudentity uses CockroachDB to store various types of data, such as users added to Cloudentity Identity Pools, configuration of client applications connected to a workspace, information about consent grants, and many more. | Mandatory | |
-| Redis | Identity Management | The Cloudentity platform uses Redis to store a variety of data types that are well-suited for key-value storage. This includes security tokens such as access tokens, which grant users access to protected resources, and identity tokens, which provide information about the user’s identity. | Mandatory | |
-| TimescaleDB | Identity Management | Cloudentity uses TimescaleDB to store audit and analytics/metrics data because it is a powerful and efficient tool for handling large amounts of time-series data. | Optional | |
-| consent admin | Consent Management | Consent administration demo application | Optional | This only provides demo capabilities, therefore it is not recommended to use this component in production. For Production you can take one of two courses of action:Use the provided template and enhance it for production usage. Develop your own web component and call Cloudentity APIs to perform consent operations. |
-| consent self-service | Consent Management | Consent self-service demo application | Optional | This only provides demo capabilities, therefore it is not recommended to use this component in production. For Production you can take one of two courses of action:Use the provided template and enhance it for production usage. Develop your own web component and call Cloudentity APIs to perform consent operations. |
-| consent page | Consent Management | Consent confirmation demo page | Optional | This only provides demo capabilities, therefore it is not recommended to use this component in production. For Production you can take one of two courses of action:Use the provided template and enhance it for production usage. Develop your own web component and call Cloudentity APIs to perform consent operations. |
-| acp-import | Identity Management Consent Management | Job to implement the default configuration for Cloudentity. | Optional | It creates the configuration for the target specification. If not used, then Cloudentity must to be configured manually. |
diff --git a/content/en/docs/Overview/Technical/infrastructure.md b/content/en/docs/Overview/Technical/infrastructure.md
deleted file mode 100644
index 86327af5..00000000
--- a/content/en/docs/Overview/Technical/infrastructure.md
+++ /dev/null
@@ -1,18 +0,0 @@
----
-title: "Infrastructure View"
-linkTitle: "Infrastructure View"
-weight: 2
-date: 2021-06-30
----
-
-The diagram below shows an outline infrastructure view of Amplify Open Banking in AWS.
-
-![Infrastructure View](/Images/Infrastructure_View_0.png)
-
-Axway recommends the following:
-
-* The solution should be deployed across multiple availability zones.
-* While the majority of cloud providers offer 3 availability zones the majority of customers deploy across 2 zones. This is generally considered sufficient for customer needs.
-* At a minimum there should be a node per zone, but it is recommended to implement more than one. Machines should be evenly distributed across zones.
-
- Refer to [Deployment - Prerequisites](/docs/deployment/prerequisites) for more details.
diff --git a/content/en/docs/Overview/_index.md b/content/en/docs/Overview/_index.md
index 5a234255..11dcef1f 100644
--- a/content/en/docs/Overview/_index.md
+++ b/content/en/docs/Overview/_index.md
@@ -7,16 +7,16 @@ date: 2021-06-22
The Amplify Open Banking solution provides the means to deliver standards-based open banking APIs while providing an extensible platform that allows an organization to realize their open banking goals.
-This section provides a general overview of the architecture. The goal is to provide customers with a complete understanding of what the solution provides, how the components are integrated, and how the solution is deployed. The document includes:
+This section provides a general overview of the solution. The goal is to provide customers with a complete understanding of what the solution provides, how the components are integrated, and how the solution is deployed and configured. The document includes:
* A [solution overview](/docs/overview/solution) that describes the solution features.
* An [functional architecture](/docs/overview/integration) that shows a number of different flows.
-* A [technical view](/docs/overview/technical) of the Kubernetes architecture and component deployment.
+
-This section does not describe:
+
diff --git a/content/en/docs/Overview/solution.md b/content/en/docs/Overview/solution.md
index d642f68d..ad822ded 100644
--- a/content/en/docs/Overview/solution.md
+++ b/content/en/docs/Overview/solution.md
@@ -7,7 +7,7 @@ date: 2021-06-22
Amplify Open Banking is built on top of five solution building blocks as shown below.
-![Solution Building Blocks](/Images/Solution_Building_Blocks.svg)
+![Solution Building Blocks](/Images/Solution-Building-Blocks.svg)
To clarify the purpose of each building block:
@@ -21,7 +21,10 @@ To clarify the purpose of each building block:
Each building block is critical to the success of your open banking platform and each building block provides a number of features. The features are based on the capabilities that the solution delivers and are summarized as shown below.
-![Solution Overview](/Images/Solution_Overview_0.svg)
+![Solution Overview](/Images/Solution-Overview.svg)
+
+
## Features
@@ -64,8 +67,6 @@ Consumer insights provides API Consumers with secure, self-service access to act
The goal of the product support contact is to give the subscriber a way to contact the product provider for any kind of assistance.
The support contact is composed of a name, email, phone number associated with office hours and alternative support methods, including: Website URL, Slack channel, or MS Teams channel.
-### Amplify Infrastructure - what should be included ?
-
### Open banking APIs
Open banking APIs provide the means to achieve compliance with standards while integrating with your backend applications.
@@ -157,19 +158,19 @@ be disabled dependent on your organization's position on market regulations.
The Infrastructure building block brings together Axway's product set to power the solution.
-{{% alert title="Note" color="primary" %}} For more information on any of these products refer to the [Axway Documentation Portal](https://docs.axway.com/).{{% /alert %}}
+#### Amplify Integration
-#### API Gateway
+The Amplify Integration provides access to and protection for your APIs using Axway's industry-leading technology. Amplify Integration is a low-code or no-code integration platform that solves simple to complex enterprise integration use cases and patterns. Primary use cases are application integration, data integration, and API-fication (getting apps to talk to each other via application programming interfaces).
-The API Gateway provides access to and protection for your APIs using Axway's industry leading technology.
+{{% alert title="Note" color="primary" %}} For more information on Amplify Integration refer to the [Axway Documentation Portal](https://docs.axway.com/bundle/amplify_integration/page/amplify_integration_guide.html).{{% /alert %}}
#### Consent management
-Our Consent Management solution is delivered using the [Cloudentity Open Banking Kit](https://cloudentity.com/open-banking/). This provides:
+Our Consent Management solution is built on top of Amplify Integration. This provides:
* The means to couple consent with the authentication, authorization, and access control to ensure that Data Recipient Applications can access only the information to which they are entitled, and nothing more.
-* An overview for your customers that allows them to browse and revoke consents for Data Recipient Applications.
* An administration view for your organization that allows you to search and manage your customers' consents.
+* An overview for your customers that allows them to browse and revoke consents for Data Recipient Applications.
Note that in some markets Consent Management must happen at the Data Recipient App and consent dashboards are prohibited.
@@ -178,21 +179,3 @@ In such cases the customer-facing aspects of Consent Management can be disabled
#### Identity management
Identity Management adds the authentication, authorization, and access control required to ensure your APIs are secure, including compliance with FAPI and local security profiles.
-
-The Cloudentity Open Banking Kit provides the default capability, but this can be swapped out for your existing Identity and Access Management solution.
-
-#### Amplify Agents
-
-Amplify agents are lightweight software applications that run on your data plane host. These agents are responsible for gathering information on what is happening in your data plane and sending it to the Amplify platform:
-
-* **Discovery Agents** automate the process of finding assets deployed in a Gateway (for example, OAS 3.0, WSDL, etc.), and sending them to the Amplify platform where they are made available in the Catalog. Consumers can subscribe to use the discovered assets, at which point the agent helps to natively provision this subscription in the Gateway.
-* **Traceability Agents** collect usage, metrics, and data plane transaction metadata and send them to the Amplify platform for additional insights. In the platform, API consumers and API providers gain visibility into the performance and behavior of the assets discovered in the data plane.
-
-#### Utilities
-
-Utilities describes the features of the solution that are developed specifically to help with the open banking solution. Utilities include:
-
-* *Mock Backends*: The solution provides mock backends for all the regulatory APIs. The Mock Backend applications are implemented using API Builder and MySQL.
-* *JWE Generator*: The solution provides JWE generator to help organizations test the APIs which require JWE payload.
-
-Customers can use these components as they see fit and can swap them out for existing functionality or use source data they may have.
\ No newline at end of file
diff --git a/content/en/docs/Reference/brazil/_index.md b/content/en/docs/Reference/brazil/_index.md
deleted file mode 100644
index 62c49ed1..00000000
--- a/content/en/docs/Reference/brazil/_index.md
+++ /dev/null
@@ -1,11 +0,0 @@
----
-title: "Open Finance Brazil"
-linkTitle: "Open Finance Brazil"
-weight: 9
----
-
-This section provides reference information relating to Open Finance Brazil.
-
-Everything you need to know about Open Finance Brazil specifications can be found in [Developer Area](https://openfinancebrasil.atlassian.net/wiki/spaces/OF/overview).
-
-Click a link below for more information.
\ No newline at end of file
diff --git a/content/en/docs/Reference/brazil/multi-authorization.md b/content/en/docs/Reference/brazil/multi-authorization.md
deleted file mode 100644
index bc649d0d..00000000
--- a/content/en/docs/Reference/brazil/multi-authorization.md
+++ /dev/null
@@ -1,40 +0,0 @@
----
-title: "Multi-party authorization pattern"
-linkTitle: "Multi-Party Authorization"
-weight: 3
-date: 2021-07-16
-type: sequence
----
-
-Multi-party authorization is a requirement of many internet banking systems. Access controls are implemented so that more than one customer must authorize access to data or making a payment. Situations such as this include joint accounts where authority of both parties is required and business accounts that apply four-eyes or greater principles. By extension, these access controls must be applied when a customer wants to share data with or initiate payment through a Third-Party App.
-
-The sequence diagram below shows the steps required once the initial approver has completed confirmation of the consent granted to the Third-Party and selected the accounts to be shared or the debit account payment is to be drawn from (where required). Please note that these requirements are a **guide** and need to be implemented **according to the both the bank's access controls** and **how they aim to contact approvers to confirm consent**.
-
-At the start of this sequence diagram:
-
-* The consent `status` for the consent is returned as `AUTHORISED`.
-* Communication of the multi-party authorization fulfillment is delegated to a given API.
-* The Third-Party has possession of an Access Token they can use to query the API.
-
-This follows the model for Multi-authorization implemented in the [UK Open Banking standards](https://openbankinguk.github.io/read-write-api-site3/v3.1.8/profiles/payment-initiation-api-profile.html#multiple-authorisation). The `status` property of the API responses returned to the TPP are as follows:
-
-* Account Information Resources API: `PENDING_AUTHORISATION`.
-* Payment Initiation API: `PART`.
-
-Other approvers are then contacted to approve the consent based on the following generic process:
-
-* Each approver is contacted using a channel known to the bank. For example, this could be by a push notification to a mobile banking app which provides a "link" to the approval workflow.
-* When the approver follows the link they are required to authenticate, using an appropriate number of factors. The number of factors is dependent on whether the bank requires Level of Assurance 2 or 3 based on their view of the [Brazil Security Profile requirements](https://openbanking-brasil.github.io/specs-seguranca/open-banking-brasil-financial-api-1_ID3.html#name-open-finance-brasil-securit).
-* Once authenticated to the required level the approver is presented with one of two screens:
- * If another approver has already refused the request for authorization a consent rejection screen should be shown.
- * If approval from all approvers is still outstanding the customer is shown the consent confirmation screen.
-* If not rejected the customer is presented with the consent confirmation screen. The details depend on whether the subject is sharing account information or making a payment, but from a multi-party perspective they should include:
- * The accounts selected by the initial approver.
- * Details of who has already approved the consent.
- * (Where applicable) the date and time by which consent needs to be approved.
-* The approver can either approve or refuse the consent. If they approve the consent their approval needs to be cached **unless they are the last approver in which case**:
- * For Account Information the Resource API datastore can be if updated to change the `status` from `PENDING_AUTHORISATION` to `AVAILABLE`.
- * For Payment Initiation the payment instruction can be executed and the `status` updated according to the status within the PIX infrastructure.
-* The approver is shown a completion screen confirming their actions.
-
-![Multi-party authorization pattern sequence](/Images/Multi_Authorization_Pattern.svg)
\ No newline at end of file
diff --git a/content/en/docs/Reference/brazil/obb-api-list.md b/content/en/docs/Reference/brazil/obb-api-list.md
deleted file mode 100644
index 86d66073..00000000
--- a/content/en/docs/Reference/brazil/obb-api-list.md
+++ /dev/null
@@ -1,38 +0,0 @@
----
-title: "List of Open Finance Brazil APIs included in Amplify Open Banking"
-linkTitle: "API List"
-weight: 2
-type: bigtable
----
-
-The table below provides the list of Open Finance Brazil APIs supported in the Amplify Open Banking solution.
-
-| Name | Phase | Guidance | URI(s) |
-| ---- | ----- | -------- | ------ |
-| Status API | 1+ | Provides the status of the APIs hosted by the bank. This is an open data API and requires no authentication for access. It is rate-limited at the thresholds described in the standards. It is assumed that this API must be implemented regardless of whether the implementor starts later than Phase 1. | /discovery/v1/status |
-| Outages API | 1+ | Provides information on outages at the the bank. This is an open data API and requires no authentication for access. It is rate-limited at the thresholds described in the standards. It is assumed that this API must be implemented regardless of whether the implementor starts later than Phase 1. | /discovery/v1/outages |
-| Service Channels API | 1 | Provides information on "channels" at the bank, including information on branches, phone numbers, and ATMs. This is an open data API and requires no authentication for access. It is rate-limited at the thresholds described in the standards. | /channels/v1/branches /channels/v1/electronic-channels /channels/v1/phone-channels /channels/v1/banking-agents /channels/v1/shared-automated-teller-machines |
-| Products and Services API | 1 | Provides information on personal and business products across a range of product types including:Current accounts. Loans. Financing. Invoice financing. Credit cards. Unarranged overdrafts. This is an open data API and requires no authentication for access. It is rate-limited at the thresholds described in the standards. | /products-services/v1/personal-accounts /products-services/v1/business-accounts /products-services/v1/personal-loans /products-services/v1/business-loans /products-services/v1/personal-financings /products-services/v1/business-financings /products-services/v1/personal-invoice-financings /products-services/v1/business-invoice-financings /products-services/v1/personal-credit-cards /products-services/v1/business-credit-cards /products-services/v1/personal-unarranged-account-overdraft /products-services/v1/business-unarranged-account-overdraft |
-| Metrics API | 1+ | Provides metrics data for consumption by the Directory. This is an open data API and requires no authentication for access. It is rate-limited at the thresholds described in the standards. It is assumed that this API must be implemented regardless of whether the implementor starts later than Phase 1. | /admin/v1/metrics |
-| Consent API | 2 | Provides the implementation of the Lodging Intent pattern that allows a TPP to create and maintain consent at the bank. It covers all Phase 2 APIs, with one-or-more permission codes per API defined in the OpenAPI document. | /consents/v2/consents /consents/v2/consents/{consentId} /consents/{consentId}/extends |
-| Resources API | 2 | The Resources API creates a bridge between the consent granted by an End User and the accounts they hold and have agreed to share. It is used by a TPP to retrieve the accounts - regardless of type - that the End User has agreed to share. Each Account ID is shared with its type and the status of the account. Note that one of the status codes - `PENDING_AUTHORISATION` - is unlikely to ever be returned where only a single End User is required to consent to access. Customer consent is required for a TPP to access this API and retrieve a customer's data. | /resources/v2/resources |
-| Customer API | 2 | The Customer API provides information on the customer who provided consent or the organization, depending on whether the customer is a personal or business customer. The endpoints support the retrieval of the following data:The identity of the customer including their legal identifier, social security number (where applicable) and address. Financial "qualification" records, namely their income. In the case of businesses this includes information on their economic activities. Any information on the customer's financial relationships, namely the products and services they hold. Customer consent is required for a TPP to access this API and retrieve a customer's data. | /customers/v2/personal/identifications /customers/v2/business/identifications /customers/v2/personal/qualifications /customers/v2/business/qualifications /customers/v2/personal/financial-relations /customers/v2/business/financial-relations |
-| Credit Card API | 2 | This API provides credit card information including limits, transactions, bills, and billed transactions. Customer consent is required for a TPP to access this API and retrieve a customer's data. | /credit-cards-accounts/v2/accounts /credit-cards-accounts/v2/accounts/{creditCardAccountId} /credit-cards-accounts/v2/accounts/{creditCardAccountId}/limits /credit-cards-accounts/v2/accounts/{creditCardAccountId}/transactions /credit-cards-accounts/v2/accounts/{creditCardAccountId}/bills /credit-cards-accounts/v2/accounts/{creditCardAccountId}/bills/{billId}/transactions /credit-cards-accounts/v2/accounts/{creditCardAccountId}/transactions-current |
-| Accounts API | 2 | This API provides account information including balances, transactions, and limits. Customer consent is required for a TPP to access this API and retrieve a customer's data. | /accounts/v2/accounts /accounts/v2/accounts/{accountId} /accounts/v2/accounts/{accountId}/balances /accounts/v2/accounts/{accountId}/transactions /accounts/v2/accounts/{accountId}/transactions-current /accounts/v2/accounts/{accountId}/overdraft-limits |
-| Loans API | 2 | This API provides information on customer loans including warranties, payments, and scheduled installments. Customer consent is required for a TPP to access this API and retrieve a customer's data. | /loans/v2/contracts /loans/v2/contracts/{contractId} /loans/v2/contracts/{contractId}/warranties /loans/v2/contracts/{contractId}/payments /loans/v2/contracts/{contractId}/scheduled-instalments|
-| Financing API | 2 | This API provides information on customer financing including warranties, payments, and scheduled installments. Customer consent is required for a TPP to access this API and retrieve a customer's data. | /financings/v2/contracts /financings/v2/contracts/{contractId} /financings/v2/contracts/{contractId}/warranties /financings/v2/contracts/{contractId}/payments /financings/v2/contracts/{contractId}/scheduled-instalments |
-| Advances API | 2 | This API provides information on customer unarranged overdrafts including warranties, payments, and scheduled installments. Customer consent is required for a TPP to access this API and retrieve a customer's data. | /unarranged-accounts-overdraft/v2/contracts /unarranged-accounts-overdraft/v2/contracts/{contractId} /unarranged-accounts-overdraft/v2/contracts/{contractId}/warranties /unarranged-accounts-overdraft/v2/contracts/{contractId}/payments /unarranged-accounts-overdraft/v2/contracts/{contractId}/scheduled-instalments|
-| Invoice Financing API | 2 | This API provides information on customer invoice financing including warranties, payments, and scheduled installments. Customer consent is required for a TPP to access this API and retrieve a customer's data. | /invoice-financings/v2/contracts /invoice-financings/v2/contracts/{contractId} /invoice-financings/v2/contracts/{contractId}/warranties /invoice-financings/v2/contracts/{contractId}/payments /invoice-financings/v2/contracts/{contractId}/scheduled-instalments |
-| Payments API | 3 | The Payments API is the core deliverable for Phase 3 of Open Finance Brazil. It incorporates two operations:The creation of consent for a single immediate payment. The execution of the payment instruction once consent is authorized. The payment instruction itself is transmitted using PIX. It therefore relies on attributes from the PIX payment set-up method e.g. QR Code made available to the payer, PIX "key" of the payee. | /payments/v2/consents /payments/v2/consents/{consentId} /payments/v2/pix/payments /payments/v2/pix/payments/{paymentId} /payments/v3/consents /payments/v3/consents/{consentId} /payments/v3/pix/payments /payments/v3/pix/payments/{paymentId}|
-| Capitalization API | 4 | The APIs described in this document refer to the Capitalization API of the OpenInsurance phase of Open Finance Brazil. | /opendata-capitalization/v1/bonds |
-| Investments API | 4 | These APIs aim at sharing data about Investments and their characteristics among the Financial Institutions participating in Open Finance Brazil. | /opendata-investments/v1/funds /opendata-investments/v1/bank-fixed-incomes /opendata-investments/v1/credit-fixed-incomes /opendata-investments/v1/variable-incomes /opendata-investments/v1/treasure-titles |
-| Exchange API | 4 | Open Finance Brazil Exchange API – Phase 4. API that returns Forex information. | /opendata-exchange/v1/online-rates /opendata-exchange/v1/vet-values |
-| Acquiring Services API | 4 | Open Finance Brazil Acquiring Services API – Phase 4. API that returns Accreditation information. | /opendata-acquiring-services/v1/businesses /opendata-acquiring-services/v1/personals |
-| Pension API | 4 | Open Finance Brazil Pension API – Phase 4. API that returns Pension information. | /opendata-pension/v1/risk-coverages /opendata-pension/v1/survival-coverages |
-| Insurance API | 4 | The APIs described in this document refer to the Insurance API of the OpenInsurance phase of Open Finance Brazil. | /opendata-insurance/v1/personals |
-| Bank Fixed Incomes API | 4 | The Bank Fixed Incomes API makes it possible to share data on bank fixed income investment products, such as listing of products, product details, product position and historical and recent movements of the customer's product. | /bank-fixed-incomes/v1/investments /bank-fixed-incomes/v1/investments/{investmentId} /bank-fixed-incomes/v1/investments/{investmentId}/balances /bank-fixed-incomes/v1/investments/{investmentId}/transactions /bank-fixed-incomes/v1/investments/{investmentId}/transactions-current |
-| Credit Fixed Incomes API | 4 | Gets the list of Fixed Income Credit operations maintained by the client at the transmitting institution and for which he has provided consent. | /credit-fixed-incomes/v1/investments /credit-fixed-incomes/v1/investments/{investmentId} /credit-fixed-incomes/v1/investments/{investmentId}/balances /credit-fixed-incomes/v1/investments/{investmentId}/transactions /credit-fixed-incomes/v1/investments/{investmentId}/transactions-current |
-| Variable Incomes API | 4 | Open Finance Brazil Variable Income operations information API – Phase 4. API that returns information on Variable Income type investment operations maintained at transmitting institutions by their clients, including data such as product information, quantity, balances in the client's position, financial movements and details of the negotiation note. | /variable-incomes/v1/investments /variable-incomes/v1/investments/{investmentId} /variable-incomes/v1/investments/{investmentId}/balances /variable-incomes/v1/investments/{investmentId}/transactions /variable-incomes/v1/investments/{investmentId}/transactions-current /variable-incomes/v1/investments/{investmentId}/broker-notes/{brokerNoteId} |
-| Treasure Titles API | 4 | API for information on operations of Treasury Direct Bonds Open Finance Brazil – Phase 4. API that returns information on investment operations of the type Treasury Direct Bonds held at transmitting institutions by its clients, including data such as product information, quantity, balances in customer position and financial movements. | /treasure-titles/v1/investments /treasure-titles/v1/investments/{investmentId} /treasure-titles/v1/investments/{investmentId}/balances /treasure-titles/v1/investments/{investmentId}/transactions /treasure-titles/v1/investments/{investmentId}/transactions-current |
-| Investment Funds API | 4 | API for investment fund operations information Open Finance Brazil – Phase 4. API that returns information on investment operations of the type Investment Funds maintained at transmitting institutions by their clients, including data such as product information, quantity, balances in position of the customer and financial transactions. | /funds/v1/investments /funds/v1/investments/{investmentId} /funds/v1/investments/{investmentId}/balances /funds/v1/investments/{investmentId}/transactions /funds/v1/investments/{investmentId}/transactions-current |
-| Foreign Exchange Operations Information API | 4 | Open Finance Brazil Foreign Exchange Operations Information API – Phase 4. API that returns information on foreign exchange operations carried out at transmitting institutions by its clients, including data such as information on the contracted operation, value of the operation in national and foreign currency, classification of the operation, form of delivery, VET and, when applicable, amount to be settled. | /exchanges/v1/operations /exchanges/v1/operations/{operationId} /exchanges/v1/operations/{operationId}/events |
diff --git a/content/en/docs/Reference/fdx/_index.md b/content/en/docs/Reference/fdx/_index.md
index c3a32cf5..fd247654 100644
--- a/content/en/docs/Reference/fdx/_index.md
+++ b/content/en/docs/Reference/fdx/_index.md
@@ -12,9 +12,13 @@ The table below provides the list of FDX APIs supported in the Amplify Open Bank
| API Name | Guidance | URI(s) |
| -------- | -------- | ------ |
-| Core | This API provides account information including balances, transactions, statements and customer information. Customer consent is required for a Data Recipient to access this API and retrieve a customer's data. | /fdx/v5/accounts /fdx/v5/accounts/{accountId} /fdx/v5/accounts/{accountId}/statements /fdx/v5/accounts/{accountId}/statements/{statementId} /fdx/v5/accounts/{accountId}/transactions /fdx/v5/accounts/{accountId}/transaction-images/{imageId} /fdx/v5/accounts/{accountId}/contact /fdx/v5/core/customers /fdx/v5/core/customers/{customerId} /fdx/v5/accounts/{accountId}/payment-networks |
-| Consent | A standardized API supporting the synchronization of consent display messaging and end user experience is required to enable Data Recipients and Data Providers to negotiate user consent on-the-fly rather than through advanced administrative setup. | /fdx/v5/consents/{consentId} /fdx/v5/consents/{consentId}/revocation |
-| Customer | Enable authenticated users who are customers of data providers to share their non-sensitive financial product information with data recipients. | /fdx/v5/customers /fdx/v5/customers/current /fdx/v5/customers/{customerId} |
+| Core | This API provides account information including balances, transactions, statements and customer information. Customer consent is required for a Data Recipient to access this API and retrieve a customer's data. | /fdx/v6/accounts /fdx/v6/accounts/{accountId} /fdx/v6/accounts/{accountId}/transactions /fdx/v6/accounts/{accountId}/contact /fdx/v6/accounts/{accountId}/payment-networks /fdx/v6/accounts/{accountId}/asset-transfer-networks |
+| Consent | A standardized API supporting the synchronization of consent display messaging and end user experience is required to enable Data Recipients and Data Providers to negotiate user consent on-the-fly rather than through advanced administrative setup. | /fdx/v6/consents/{consentId} /fdx/v6/consents/{consentId}/revocation |
+| Event Publication and Subscription | API to facilitate publication of events and to provide a mechanism to allow entities to manage subscriptions | /fdx/v6/events/notification-subscriptions /fdx/v6/events/notification-subscriptions/{subscriptionId} /fdx/v6/events/notifications |
+
+
+
\ No newline at end of file
diff --git a/content/en/docs/Release-Notes/3.1.0_relnotes.md b/content/en/docs/Release-Notes/3.1.0_relnotes.md
deleted file mode 100644
index e9de2b52..00000000
--- a/content/en/docs/Release-Notes/3.1.0_relnotes.md
+++ /dev/null
@@ -1,45 +0,0 @@
----
-title: "Open Banking v3.1.0 Release Notes"
-linkTitle: "Open Banking v3.1.0 Release Notes"
-weight: 20
----
-
-Release notes for Amplify Open Banking v3.1.0. In this update, we have added support for Financial Data Exchange (FDX) APIs. These new APIs will allow customers in North America to deploy the Amplify Open Banking solution.
-
-Axway API Gateway is upgraded to the "Nov 2022 release(7.7-20221130)" in the FDX deployment.
-
-In addition, we have made a significant update and restructuring of our documentation to reflect these changes.
-
-## Upgrade existing deployment
-
-Follow the [upgrade instructions](/docs/deployment/upgrade) to apply this update.
-
-## New features and enhancements for v3.1.0
-
-The following new features and enhancements are available in this update.
-
-### Support for FDX APIs
-
-We have added support for FDX APIs Core, Moneymovement & Tax. For the full list of FDX API endpoints supported, see [FDX API List](/docs/reference/fdx/#list-of-fdx-apis-included-in-amplify-open-banking).
-
-### Addition of Amplify Marketplace
-
-Developer Portal is now replaced with Marketplace for Open Banking. Open Banking APIs can be published in Amplify Marketplace.
-
-### Updates and Enhancements for Open Finance Brazil
-
-This release includes the following updates and features to keep support of Open Finance Brazil specs:
-
-* Upgrade of Axway API Gateway and Manager to February 2023 - including new security enhancements and features - [APIM Release Notes](https://docs.axway.com/bundle/axway-open-docs/page/docs/apim_relnotes/20230228_apimgr_relnotes/index.html).
-* Update of Amplify Open Banking Authorization and Consent Management components to Cloudentity v2.11.0-2 - [Release Notes](https://cloudentity.com/developers/deployment-and-operations/release-notes/rsnotes-2.11.0/ )
-* Update for Open Finance Brazil phase 4a APIs specs considering the new endpoints (capitalization v1.0.0-rc2.0, acquiring-services v1.0.0,Insurance 1.0.0-rc1.0,Investment v1.0.0, exchange v1.0.0,pension v1.0.0-rc1.0 ) - [Open Data](https://openfinancebrasil.atlassian.net/wiki/spaces/OF/pages/17367790/Dados+Abertos).
-* Mock backend APIs for Open Finance Brazil phase 2 v2 are updated to support the functional tests.
-* Consent flow is updated to fix a bug of consent request date due to timezone configuration.
-
-## Known Issues for v3.1.0
-
-The following are known issues for this update.
-
-### External clients are not created in API Manager applications
-
-External Client is not configured in the applications created during the installation of `open-banking-fdx-apim-config` helm chart. Use API Manager to add the external client configuration in existing applications.
diff --git a/content/en/docs/Release-Notes/3.2.0_relnotes.md b/content/en/docs/Release-Notes/3.2.0_relnotes.md
deleted file mode 100644
index 7c0d3255..00000000
--- a/content/en/docs/Release-Notes/3.2.0_relnotes.md
+++ /dev/null
@@ -1,66 +0,0 @@
----
-title: "Open Banking v3.2.0 Release Notes"
-linkTitle: "Open Banking v3.2.0 Release Notes"
-weight: 19
----
-
-In this update we have upgraded FDX APIs to v5.2.1 and added support for Consent, Customer and Recipient Registration v5.2.1 APIs.
-
-In addition, we have added Phase4b APIs for Open Finance Brazil.
-
-This update also includes migration to YAML Entity Store from existing XML based API Gateway configuration.
-
-## Upgrade existing deployment
-
-Follow the [upgrade instructions](/docs/deployment/upgrade) to apply this update.
-
-## New features and enhancements for v3.2.0
-
-The following new features and enhancements are available in this update.
-
-### Upgrade of FDX APIs to v5.2.1
-
-* Core and Tax APIs are upgraded to v5.2.1
-* Consent, Customer, Fraud and Recipient Registration v5.2.1 APIs are added in this release. For updated FDX API list, see [FDX API List](/docs/reference/fdx/#list-of-fdx-apis-included-in-amplify-open-banking).
-
-### Open Finance Brazil updates
-
-* Consent v2.2 beta1 support
-* Phase4B APIs support
-* Payment Initiation V3 support
-* Phase2 v2.0.1 and 2.1.0 APIs update
-
-### API Management changes
-
-* API Gateway is upgraded to "May 2023 release(7.7-20230530)". For API Gateway release notes, see [API Gateway and API Manager 7.7 May 2023 Release Notes](https://docs.axway.com/bundle/axway-open-docs/page/docs/apim_relnotes/20230530_apimgr_relnotes/index.html).
-* Migrated the API Gateway configuration from XML based FED to YAML Entity Store. For more information on YAML Entity store, see [YAML configuration](https://docs.axway.com/bundle/axway-open-docs/page/docs/apim_yamles/index.html).
-* Added merge dir capabilities and Entity Store externalization. For more details on this topic, see [FDX API Management Configuration](/docs/deployment/installation/api-management/fdx-apim) for FDX and [Open Finance Brazil API Management Configuration](/docs/deployment/installation/api-management/obb-apim/) for Open Finance Brazil deployments.
-* Some improvements to the Helm chart for the deployment of API Gateway, discovery and traceability agents.
-
-API Gateway changes specific to Open Finance Brazil deployments:
-
-* Removed dependency from envSettings.props file moving some variables to environment variables.
-* Updated filebeat for backwards compatibility
- * Upgraded from version 7.9 to 8.10.4
-
-API Manager changes specific to Open Finance Brazil deployments:
-
-* Upgraded to the latest apimcli image 1.14.2
-* Removed built in configuration files and added them as customizable configmaps
-* Removed deprecated APIs
-* Introduced APIM Settings configurable via values.yaml
-
-Added a new module KPS-Config for Open Finance Brazil deployments:
-
-* Must be executed after APIM full installation
-
-### Cloudentity Updates
-
-This release includes the Cloudentity v2.19.0-1. This new version includes:
-
-* Initial support for Open Finance Consent Renewal specification new endpoints:
- * GET /open-banking/consents/v2/consents/{consentID}/extends
- * POST /open-banking/consents/v2/consents/{consentID}/extends
-* Please note that for FDX deployments, Cloudentity v2.15.1-1 must be used.
-
-For more information on Cloudentity changes, see [Cloudentity Release Notes](https://cloudentity.com/developers/deployment-and-operations/release-notes/).
diff --git a/content/en/docs/Release-Notes/_index.md b/content/en/docs/Release-Notes/_index.md
index ba8200bb..3c7e0e46 100644
--- a/content/en/docs/Release-Notes/_index.md
+++ b/content/en/docs/Release-Notes/_index.md
@@ -1,4 +1,4 @@
----
+
diff --git a/content/en/docs/Validation/brazil/_index.md b/content/en/docs/Validation/brazil/_index.md
deleted file mode 100644
index 982fea0c..00000000
--- a/content/en/docs/Validation/brazil/_index.md
+++ /dev/null
@@ -1,9 +0,0 @@
----
-title: "Open Finance Brazil"
-linkTitle: "Open Finance Brazil"
-weight: 5
-date: 2023-03-22
----
-Validate solution deployment, configuration, and conformance using Postman and official conformance certification tests.
-
-Click a link below for more information.
\ No newline at end of file
diff --git a/content/en/docs/Validation/brazil/brazil-certification.md b/content/en/docs/Validation/brazil/brazil-certification.md
deleted file mode 100644
index 09b29b42..00000000
--- a/content/en/docs/Validation/brazil/brazil-certification.md
+++ /dev/null
@@ -1,46 +0,0 @@
----
-title: "Conformance Test Suite"
-linkTitle: "Conformance Test Suite"
-weight: 3
-date: 2021-09-02
----
-
-As part of the certification process, the customer´s platforms should be compliant with Open Finance Brazil conformance suite.
-
-*
-
-This section describes the setup tests that are necessary to configure the environment to run the Open Finance Brazil conformance tests.
-
-Use one of the following ways to run the tests:
-
-* On the Open Finance Brazil platform . You must have an account to login.
-* On your local test platform that you can deploy by following these instructions: .
-
-Then, you should be able to create and run new test plans.
-
-![Conformance Suite : Create Plan](/Images/conformance-suite/create-plan-ob.png)
-
-Create a new test plan:
-
-* To create a new test plan for the open data API, registration/transactional data and services, among other necessary OBB validations;
-* To configure the new test plan, the information will be found in the Cloudentity - (Cloudentity Admin Portal), in Workspace: Openbanking Brasil - Applications.
-
-View all available test logs:
-
-* All past testicle logs remain available for consultation.
-
-View Published Test Logs:
-
-* All public testicle logs remain available for viewing.
-
-View all available test plans:
-
-* All past test plans remain available for consultation, making it possible to visually check the validated or not validated scenarios.
-
-View published test plans:
-
-* All public test plans are available for further reference.
-
-View API documentation
-
-* Documents about the compliance engine
diff --git a/content/en/docs/Validation/brazil/openid-certification.md b/content/en/docs/Validation/brazil/openid-certification.md
deleted file mode 100644
index d5760bf3..00000000
--- a/content/en/docs/Validation/brazil/openid-certification.md
+++ /dev/null
@@ -1,155 +0,0 @@
----
-title: "OpenID Security Conformance"
-linkTitle: "OpenID Security Conformance"
-weight: 2
-date: 2021-09-02
----
-
-As part of the certification process, the customer´s platforms should be compliant with OpenID Foundation security tests:
-
-*
-
-We have three different set of tests:
-
-* *DCR tests*: dynamic client registration
-* *FAPI Advanced test*: Financial-grade API
-* *FAPI-CIBA-ID1*: Authorization server test
-
-This section describes the setup tests that are necessary to configure the environment to run the security tests.
-
-## Conformance test suite
-
-Use one of the following ways to run the tests:
-
-* On the Open ID platform . You must have an account to login.
-* On your local test platform that you can deploy by following these instructions: .
-
-Then, you should be able to create and run new test plans.
-
-![Conformance Suite : Create Plan](/Images/conformance-suite/create-plan.png)
-
-## Dynamic Client Registration Test
-
-The Dynamic Client Registration test validates the TPP creation on the Authorization Server by the Central Directory request.
-
-### Getting Central Directory information
-
-It is important to run the test to get the following information from the [Central Directory Sandbox](https://web.sandbox.directory.openbankingbrasil.org.br/):
-
-* *Client ID*: Central Directory client ID to register.
-![client-id](/Images/central_directory_brazil_clientid.png)
-* *BRSEAL*: Message certificate (cert and key) used for JWKS.
-![BRSEAL](/Images/central_directory_brazil_brseal.png)
-* *BRCAC*: Transport certificate used for MTLS communication.
-![BRCAC](/Images/central_directory_brazil_brcac.png)
-
-{{% alert title="Note" color="primary" %}} You can find more details on [Central Directory Operation Guide](https://openfinancebrasil.atlassian.net/wiki/spaces/OF/pages/17378602/Guia+de+Opera+o+do+Diret+rio+Central) (in Portuguese).{{% /alert %}}
-
-### Get the application declared in APIM
-
-
-
-{{% alert title="Note" color="primary" %}} This release has a limitation that the ClientID is not automatically created on APIM.{{% /alert %}}
-
-On APIM there is an organization named *Testing* to support this test. And a new Application for the ClientID that is used for this test needs to be created.
-
-1. Create a new Application on the organization named *Testing* with access to the payment API.
-
-2. Get the Application ID. Use the API call to get all applications and find the *id* corresponding to your new application.
-
- ```bash
- curl --user apiadmin https://api-manager./api/portal/v1.3/applications
- ```
-
-3. Create the OAuth Credentials for the application:
-
-```bash
-curl --location --request POST 'https://api-manager./api/portal/v1.3/applications/5e321c00-5e5e-4167-a295-dc05e40c4e50/oauth' \
---user apiadmin \
---header 'Content-Type: application/json' \
---data-raw '{
- "id": "c4fodmqo889qjstf7ibg",
- "cert": null,
- "type": "public",
- "enabled": true,
- "redirectUrls": [https://www.certification.openid.net/test/a/OB-EKS-DEV/callback"],
- "corsOrigins": ["*"],
- "applicationId": "5e321c00-5e5e-4167-a295-dc05e40c4e50"
-}'
-```
-
-{{% alert title="Note" color="primary" %}} The *applicationId* appears in the URL request (POST `https://hostname:port/api/portal/v1.3/applications/$applicationId/oauth`) and the JSON data as *applicationId*. And the *client-id* used for oauth appears in the JSON data as *id*.{{% /alert %}}
-
-### Certificate configuration
-
-Make sure the corresponding CAs are configured in the Amplify Open Banking solution by following each section of [Certificate Management](/docs/configuration/certificate-management).
-
-### Create the DCR test plan
-
-1. Create a new plan, and then select **Dynamic Client Registration Authorization server test**:
-![Conformance Suite : Create Plan](/Images/conformance-suite/dcr-plan-select.png)
-
-2. Use the JSON tab to import the [conformance-test-dcr.json](https://axway-open-banking-docs.netlify.app/sample-files/conformance-test-dcr.json) sample JSON test configuration.
-
-3. Click the **Form** tab to customize the following:
- * *Test Information*: Include your company name and/or environment info. Decide whether you want to publish the result or not.
- * *Server*: Provide the Authorization server URL (keep /.well-known/openid-configuration).
- * *Client*: Change JWKS with RSEAL information.
- * *TLS certificates for client*: Change certificate and key with BRCAC information.
- * *Directory*: Change client ID with the new TPP client ID to register.
-
-## Financial-grade API (FAPI) advanced tests
-
-This section includes the steps to complete the FAPI advanced test.
-
-### TPP configurations
-
-For the FAPI advanced test you need to have two registered TPPs.
-
-Make sure you have the following information from the [Central Directory Sandbox](https://web.sandbox.directory.openbankingbrasil.org.br/) for each TPP:
-
-* *BRSEAL*: Message certificate (cert and key) used for JWKS.
-* *BRCAC*: Transport certificate used for MTLS communication.
-
-Make sure that the two test TPPs are configured in APIM:
-
-* Connect to the API Manager UI.
-* Under Client - application, you should see an application for each TPP.
-* In each application an OAuth clientId should be configured in the Authorization section.
-
-Make sure that the two test TPPs are configured in Cloudentity:
-
-* Connect to Cloudentity, and then select the Open Banking workspace.
-* Under Application, you should be able to find each TPP with the same application name as in APIM with the same clientID.
-* Each application should be configured with a correct Redirect URI: `https://www.certification.openid.net/test/a//callback`. This test alias is the one used when creating the test plan later.
-![app-details](/Images/acp-tpp-app-details.png)
-* Each application should be configured with a correct client authorization method:
- * Choose **Private Key JWT** for tests with JWT.
- * Choose **TLS Client authentication** for tests with MTLS.
-![app-details](/Images/acp-tpp-auth-method.png)
-* Each application should be configured with correct client authorization details.
-![app-details](/Images/acp-tpp-auth-identifier.png)
-
-### Solution configuration
-
-Make sure the corresponding CAs are configured in the Amplify Open Banking solution:
-
-* Including the CA cert of each TPP on IngressMTLSCA entry of `values.yaml` of the APIM package. See detailed instructions in [Certificate Management - MTLS](/docs/configuration/certificate-management/mtls).
-* Including the CA cert of each TPP on the Cloudentity - Settings - Authorization tab. See detailed instructions in [Certificate Management - MTLS](/docs/configuration/certificate-management/mtls).
-* Update the filters Jwt-Verify and Jwt-Sign, updating the JWKS certificate (BRCAC). See detailed instructions in [Certificate Management - JWKS](/docs/configuration/certificate-management/jwks).
-
-### Create the FAPI advanced test plan
-
-1. Create a new plan, and then select **FAPI Authorization server test**:
-![Conformance Suite : Create Plan](/Images/conformance-suite/fapi-plan-select.png)
-
-2. Use the JSON tab to import the [conformance-test-fapi.json](https://axway-open-banking-docs.netlify.app/sample-files/conformance-test-fapi.json) sample JSON test configuration.
-
-3. Click the **Form** tab to customize the following:
- * *Test Information*: Include your company name and/or environment info. The alias should be the same as in the apps Redirect URI. Decide whether you want to publish the result or not.
- * *Server*: Provide the Authorization server URL (keep /.well-known/openid-configuration).
- * *Client*: Set the OAuth client Id and JWKS with RSEAL information of TPP1.
- * *TLS certificates for client*: Change the certificate and key with BRCAC information of TPP1.
- * *Second client*: Set the OAuth client Id and JWKS with RSEAL information of TPP2.
- * *Second client TLS certificates*: Change the certificate and key with BRCAC information of TPP2.
- * *Resource*: Update the URL with the domain names and update the organization id.
\ No newline at end of file
diff --git a/content/en/docs/Validation/brazil/postman-obb.md b/content/en/docs/Validation/brazil/postman-obb.md
deleted file mode 100644
index 083ece9d..00000000
--- a/content/en/docs/Validation/brazil/postman-obb.md
+++ /dev/null
@@ -1,227 +0,0 @@
----
-title: "Functional tests with Postman"
-linkTitle: "Testing with Postman"
-weight: 1
-date: 2021-09-02
----
-
-The Amplify Open Banking solution includes Postman collections for Open Banking APIs.The Postman collections are available to download through the Marketplace.
-
-Each collection includes a script that simulates a sequence of API calls to verify Open Banking API specification compliance. For example, the Accounts or Payments collections includes the sequence of user authentication, user consent, and calls to methods of Accounts API or the Payments API. Successful execution of the Postman collection validates the installation of the solution and Open Banking API specification compliance. Postman collections help Third-Party Providers (TPP) to learn how to use the APIs.
-
-## Retrieve the Postman files
-
-Retrieve the postman files.
-
-1. Go to the Marketplace and click Products to access the API Product.
-2. Browse to the API Product you would like to test and go to Documentation tab. Alternatively you can click on How To Consume APIs section from the Overview tab.
-3. Click the Postman Collection and Postman Environment links to download the Collection and Environment files.
-"Note" Postman collections also have their own documentation and you can follow these instructions within postman after importing the collection.
-
-## Import the collection files into Postman
-
-Import the Postman collection files.
-
-1. Import the collection files into Postman. Each API has its own Postman collection. The environment file is unique for the solution environment. The environment file configurations contain parameters like solution hostnames and parameters that are used to call the APIs offered in the solution.
-![payment-api-postman-file-import](/Images/postman-import.png)
-
-2. Once imported, select the collection in the left pane, and then select the environment in the top right corner of postman.
-
-3. Update the environment details, with _client-id_ and the _private-key_ corresponding to the TPP client certificate for message encryption. The private key has a signature usage, it is used to sign messages and JWT.
-![payment-api-postman-environment](/Images/postman-environment.png)
-
-4. For the Payment API, modify the following parameters that correspond to the solution environment installation:
- * _organizationId_: The Account Service Payment Service Provider (ASPSP). This identifier corresponds to the bank's identifier in the central bank's registry.
- * _date_: Date the payment consent is valid for the payment initiation.
- * _cnp_: CNPJ (Brazilian National Registry of Legal Entities) of the payment initiator (the entity or the person who initiates the payment).
-
-## Configure Postman settings
-
-Configure Postman for testing Open Banking APIs.
-
-1. Click **Settings** (the cog icon) in Postman.
-
-2. Click **General**. Ensure **Automatically follow redirects** is set to OFF and turn off **SSL certificate validation**.
-![payment-api-postman-settings](/Images/postman-settings1.png)
-
-3. Click **Certificates**. Ensure a TPP client certificate is installed for the target environment. If not:
- * Click **Add Certificate**.
- * Type the target host for the Authorization server and leave the port empty (if exposed on 443 as by default).
- * Select the certificate and private key (CRT file and KEY file respectively) to be used for MTLS connection.
- * Click **Add**.
- * Click **Add Certificate**.
- * Type the target host for the API MTLS server and leave the port empty (if exposed on 443 as by default).
- * Select the certificate and private key (CRT file and KEY file respectively) to be used for MTLS connection.
- * Click **Add**.
-
-![payment-api-postman-settings](/Images/postman-settings2.png)
-
-## Test the API collection
-
-Follow the collection flow step-by-step for each of the APIs.
-
-Some APIs require user consent (account, credit card, payment, and so on). You must copy and paste the consent data or urls from the browser into the Postman collections steps for APIs that require consent.
-
-## Examples
-
-This section includes examples for testing the Accounts and Payment APIs.
-
-### Accounts API
-
-Use Postman to test the Accounts API.
-
-#### Start the steps in Postman to test the Accounts API
-
-Start testing the Accounts API in Postman.
-
-1. Select Step 0, and then click _Send_ to get a "200 OK" response code. This step is required only once for the environment. This sets a global variable that is useful for next steps in the sequence.
-![accounts-api-postman-step0](/Images/accounts-api-postman-step0.png)
-
-2. Select Step 1 and mouse-over on the `{{client-id}}` variable in the request body to make sure the current value is correct. If not, change it from the environment details (Use the _Eye_ icon on th top left corner and _Edit_ button).
-
-3. Click _Send_ to get the Client Credentials Grant for accounts to get a "200 OK" response code and the response body with the _access\_token_.
-![accounts-api-postman-step1](/Images/accounts-api-postman-step1.png)
-
-4. Select Step 2 and check the request body corresponds to the required permissions.
-
-5. Click _Send_ to create the consent request to get "201 Created" response code and the response body with _consentId_.
-![accounts-api-postman-step2](/Images/accounts-api-postman-step2.png)
-The Step 3 is about signing the payload with the client private key. In real life, this step would be done on the client side only.
-
-6. Mouse-over on the `{{jwe-server}}` variable in the request URL to check if the current value matches an existing JWE-generator service.
-{{% alert title="Warning" color="warning" %}} In this step the private key is sent to the signing service. Please use test/development keys only.{{% /alert %}}
-
-7. Click _Send_ to create the consent request to get "201 Created" as response code and the response body includes a _consentId_ value.
-Alternatively, skip this step and directly set the `{{jwe_request}}` variable with the signed payload required for Step 4.
-![accounts-api-postman-step3](/Images/accounts-api-postman-step3.png)
-
-8. Select Step 4 and mouse-over on the `{{jwe_request}}` variable in the request body to verify the current value is set.
-
-9. Click _Send_ to create the consent request to get a "302 Found" response code and the link to the consent login page.
-![accounts-api-postman-step4](/Images/accounts-api-postman-step4.png)
-
-#### Complete the steps in the UI to test the Accounts API
-
-Continue testing the Accounts API in the UI.
-
-1. Open the link to the consent login page in your browser and login with an authorized user. The login page depends on the Authorization server configuration.
-![accounts-api-postman-step4-login](/Images/accounts-api-postman-step4-login.png)
-
-2. Select the bank accounts that correspond to the user consent, and confirm. The consent page depends on the Authorization server configuration.
-![accounts-api-postman-step4-consent](/Images/accounts-api-postman-step4-consent.png)
-The redirect URL of the TPP client app should include `https://oauth.pstmn.io/v1/callback` and the link back to Postman with the authorization code to use for the next step.
-
-3. Copy this code from the redirected URL.
-![accounts-api-postman-step4-copy-code](/Images/accounts-api-postman-step4-copy-code.png)
-
-#### Complete the steps in Postman to test the Accounts API
-
-Finish testing the Accounts API in Postman.
-
-1. Select Step 5 and paste the code in the `code` value of the request body form.
-
-2. Click _Send_ to create the account access token to get a "200 OK" response code and the response body includes an _access\_token_ value.
-![accounts-api-postman-step5](/Images/accounts-api-postman-step5.png)
-
-3. Select the "GET accounts" method to verify access to all accounts with user consents.
-
-4. Click _Send_ to get the accounts to get a "200 OK" response code and the response body includes the list of accounts with user consent.
-![accounts-api-postman-get-all](/Images/accounts-api-postman-get-all.png)
-
-5. Select the "GET account by accountId" method to verify access to a specific account. Mouse-over on the `{{accountId}}` variable in the request URL to make sure the current value matches the account information.
-
-6. Click _Send_ to get the account to get a "200 OK" response code and the response body includes the details of the requested account.
-![accounts-api-postman-get-account](/Images/accounts-api-postman-get-account.png)
-
-7. Select "GET balances by accountId" method to test the access to balances of a specific account. Mouse-over on the `{{accountId}}` variable in the request URL to make sure the current value matches the account information.
-
-8. Click _Send_ to get the account balances. Make sure you get a "200 OK" return code and the response body includes the balances of the requested account.
-![accounts-api-postman-get-balance](/Images/accounts-api-postman-get-balance.png)
-
-9. Select the "GET overdraft limits by AccountId" method to test access overdraft limits of a specific account. Mouse-over on the `{{accountId}}` variable in the request URL to verify if the current value matches the account information.
-
-10. Click _Send_ to get the account overdraft limits. Make sure you get a "200 OK" return code and the response body includes the overdraft limits of the requested account.
-![accounts-api-postman-get-overdraft-limits](/Images/accounts-api-postman-get-overdraft-limits.png)
-
-11. Select the "GET transactions by accountId" method to verify the transactions list of a specific account. Mouse-over on the `{{accountId}}` variable in the request URL to verify if the current value matches the account information.
-
-12. Click _Send_ to get the account transactions to get a "200 OK" response code and the response body includes the transactions list of the requested account.
-![accounts-api-postman-get-transactions](/Images/accounts-api-postman-get-transactions.png)
-
-### Payment API
-
-Use Postman to test the Payment API.
-
-#### Start the steps in Postman to test the Payment API
-
-Start testing the Payment API in Postman.
-
-1. Select Step 0 and click _Send_. Make sure you get a "200 OK" return code. This step is required only once by environment. This will set a global variable that is useful for next steps.
-![payment-api-postman-step0](/Images/payment-api-postman-step0.png)
-
-2. Select Step 1 and mouse-over on the `{{client-id}}` variable in the request body to make sure the current value is correct. If not, change it from the environment details (Use the _Eye_ icon on th top left corner and _Edit_ button).
-
-3. Click _Send_ to get Client Credentials Grant for payments. Make sure you get a "200 OK" return code and the response body includes an _access\_token_.
-![payment-api-postman-step1](/Images/payment-api-postman-step1.png)
-
-4. Select Step 2 and check the request body payload that is built is the _Pre-request Script_ tab corresponds to the payment consent you need.
-
-5. Click _Send_ to create the consent request. Make sure you get a "201 Created" return code. The response body should be a "application/jwt" content type.
-![payment-api-postman-step2](/Images/payment-api-postman-step2.png)
-You can easily decode the response body by using JWT libraries or the online decoder available on
-Make sure it includes a _consentId_, the payment details and the status "AWAITING_AUTHORIZATION".
-![payment-api-postman-step1](/Images/payment-api-postman-step2-decoded.png)
-
-6. The Step 3 is about signing the payload with the client private key. In real life, this step would be done on the client side only.
-
-7. Mouse-over on the `{{jwe-server}}` variable in the request URL to make sure the current value is a match to an existing JWE-generator service. If not, you can change the variable from the environment details (Use the _Eye_ icon on th top left corner and _Edit_ button).
-{{% alert title="Warning" color="warning" %}} In this step the private key will be sent to the signing service. Please only use test/development keys.{{% /alert %}}
-
-8. Click _Send_ to create the consent request. Make sure you get a "201 Created" return code and the response body includes a _consentId_.
-Alternatively, you can skip this step and directly set the `{{jwe_request}}` variable with the signed payload required for Step 4.
-![payment-api-postman-step3](/Images/payment-api-postman-step3.png)
-
-9. Select Step 4 and mouse-over on the `{{jwe_request}}` variable in the request body to make sure the current value is set.
-
-10. Click _Send_ to create the consent request. Make sure you get a "302 Found" return code and the link to the consent login page.
-![payment-api-postman-step4](/Images/payment-api-postman-step4.png)
-
-#### Complete the steps in the UI to test the Payment API
-
-Continue testing the Payment API in the UI.
-
-1. Open the link in your browser and login with an authorized user. The login page depends on your Authorization server configuration.
-![payment-api-postman-step4-login](/Images/payment-api-postman-step4-login.png)
-
-2. Select the bank account to be used for the payment and the payment method.
-![payment-api-postman-step4-consent](/Images/payment-api-postman-step4-consent1.png)
-{{% alert title="Note" color="primary" %}} Thee consent page design depends on your Authorization server configuration.{{% /alert %}}
-
-3. Confirm the consent for the payment.
-![payment-api-postman-step4-consent](/Images/payment-api-postman-step4-consent2.png)
-The redirect URL of the TPP client app should include `https://oauth.pstmn.io/v1/callback` so that you get a link back to Postman with the authorization code to use for the next step. Copy this code from the redirected URL.
-![payment-api-postman-step4-callback](/Images/payment-api-postman-step4-callback.png)
-
-#### Complete the steps in Postman to test the Payment API
-
-Finish testing the Accounts API in Postman.
-
-1. Select Step 5 and paste the code in the `code` value of the request body form.
-
-2. Click _Send_ to create the account access token. Make sure you get a "200 OK" return code and the response body includes an _access\_token_.
-![payment-api-postman-step5](/Images/payment-api-postman-step5.png)
-
-3. Select Step 6 and check the request body payload that is built is the _Pre-request Script_ tab corresponds to the payment you need.
-
-4. Click _Send_ to post the payment. Make sure you get a "201 Created" return code and the response body should be a "application/jwt" content type. You can decode it as previously to check the payment status is no more awaiting for authorization.
-![payment-api-postman-step6](/Images/payment-api-postman-step6.png)
-
-5. Select Step 7 if you want to test getting the payment details again. Mouse-over on the `{{paymentId}}` variable in the request URL to make sure the current value match the payment you have just posted.
-
-6. Click _Send_ to get the payment. Make sure you get a "200 OK" return code and the response body should be a "application/jwt" content type, that you can decode as previously to check the payment details.
-![payment-api-postman-step7](/Images/payment-api-postman-step7.png)
-
-7. Select Step 8 if you want to test getting the consent details again. Mouse-over on the `{{paymentConsentId}}` variable in the request URL to make sure the current value matches the consent you posted initially.
-
-8. Click _Send_ to get the consent. Make sure you get a "200 OK" return code and the response body should be a "application/jwt" content type, that you can decode as previously to check the consent details.
-![payment-api-postman-step8](/Images/payment-api-postman-step8.png)
diff --git a/content/en/docs/Validation/fdx/_index.md b/content/en/docs/Validation/fdx/_index.md
index 26b740a7..d54c2ce6 100644
--- a/content/en/docs/Validation/fdx/_index.md
+++ b/content/en/docs/Validation/fdx/_index.md
@@ -9,27 +9,33 @@ Validate solution deployment, configuration, and conformance using Postman.
## Testing with Postman
-The Amplify Open Banking solution includes Postman collections for FDX APIs. The Postman collections are available to download through the Marketplace.
-
+The Amplify Open Banking solution includes Postman collections for FDX APIs.
Each collection includes a script that simulates a sequence of API calls to verify FDX API specification compliance. For example, the Core API collection includes the sequence of user authentication, user consent, and calls to methods of Core API. Successful execution of the Postman collection validates the installation of the solution and FDX API specification compliance. Postman collections help Data Recipients (DR) to learn how to use the FDX APIs.
### Retrieve the Postman files
-Retrieve the postman files.
+1. Download the Postman collections' file from here [Postman Collection](/postman-collection/FDX-Demo-postman-collection.json)
+2. Download the environment file from here [Postman Environment File](/postman-collection/FDX-Demo-postman-environment.json)
+
+{{% alert title="Note" color="primary" %}} Postman collections also have their own documentation. You can follow these instructions within Postman after importing the collection.{{% /alert %}}
+
+### Import the collection files / environment file into Postman
-1. Go to the Marketplace and click **Products** to access the API Product.
-2. Browse to the API Product you would like to test and go to **Documentation** tab. Alternatively you can click on `How To Consume APIs` section from the **Overview** tab.
-3. Click the **Postman Collection** and **Postman Environment** links to download the Collection and Environment files.
+1. Open Postman and go to the *Collections* tab and import the *FDX-postman-collection.json* file. Each API has its own Postman collection.
+ Refer to the image for steps:
-{{% alert title="Note" color="primary" %}} Postman collections also have their own documentation and you can follow these instructions within postman after importing the collection.{{% /alert %}}
+ ![import postman collection](/Images/import_collection.png)
-### Import the collection files into Postman
+ ![import postman collection](/Images/import_collection_step2.png)
-Import the Postman collection files.
+2. Similarly to importing the collection files, go to the *Environments* tab in the Postman and import the *FDX-postman-environment.json* file. The environment file configurations contain parameters like solution hostnames and parameters that are used to call the APIs offered in the solution.
+ Refer to the image for steps:
-1. Import the collection files into Postman. Each API has its own Postman collection. The environment file is unique for the solution environment. The environment file configurations contain parameters like solution hostnames and parameters that are used to call the APIs offered in the solution.
+ ![import postman environment](/Images/import_environment.png)
-2. Once imported, select the collection in the left pane, and then select the environment in the top right corner of postman.
+3. Once imported, select the collection in the left pane, and then select the environment in the top right corner of Postman.
+
+ ![select collection and environment](/Images/import_collection_set_env.png)
### Configure Postman settings
@@ -57,7 +63,7 @@ Some APIs require user consent for example Core API. You must copy and paste aut
### Examples
-This section includes examples for testing the FDX Core API. At this moment it is assumed that collection and environment files are imported and settings are updated in Postman using the steps above.
+This section includes examples for testing the FDX Core API. At this moment, it is assumed that collection and environment files are imported and settings are updated in Postman using the steps above.
#### FDX Core API
@@ -65,9 +71,14 @@ Use Postman to test the FDX Core API. Before sending any request make sure that
##### Start the steps in Postman to test the Core API
-* Select Step 1, Data Recipient (DR) initiates a POST request to Data Provider's (DP’s) POST /par endpoint using the Pushed Authorization Request (PAR) method
- * The *authorization_details* request parameter is defined in pre-request scripts and set as collection variable. Placeholders of all types of consents exist and can be used.
- * Once you get the response, go to **Visualize** tab and copy the available link. You need to use this link in the browser of your choice and complete login.
+1. Get Access token:
+ * Select Step 0.2 to generate a JWT token corresponding to the request body for consent.
+
+ **Note:** This step is not part of our provided APIs. It simulates generating a JWT token containing the request body information needed for the POST /par request in the next step. The Data Recipient (DR) will implement this in their application to encrypt the consent grant request body into a JWT token.
+
+2. Select Step 1, Data Recipient (DR) initiates a POST request to Data Provider's (DP’s) POST /par endpoint using the Pushed Authorization Request (PAR) method:
+ * The `authorization_details` request parameter is defined in pre-request scripts and set as collection variable. Placeholders of all types of consents exist and can be used.
+ * Once you get the response, go to the *Visualize* tab and copy the available link. Use this link in the browser of your choice and complete login.
##### Complete the steps in the Browser to test the Core API
@@ -78,13 +89,14 @@ Continue testing the Core API in the Browser.
* Select the bank accounts that correspond to the user consent, and confirm. The consent page depends on the Authorization server configuration.
The redirect URL of the DR client app should include `https://oauth.pstmn.io/v1/callback` and the link back to Postman with the authorization code to use for the next step.
-* Copy the value of query parameter *code* from the redirected URL.
+* Copy the value of query parameter `code` from the redirected URL.
##### Complete the steps in Postman to test the Core API
Finish testing the Core API in Postman.
* Select Step 2 and paste the code in the `code` value of the request body form.
- * Click *Send* to get the access token. You should get a **200 OK** response code and the response body includes an *access_token* value.
+ * Click **Send** to get the access token. You should get a **200 OK** response code with `access_token` value in the response body.
-* Once you gets the *access_token* in response you are ready to call rest of the API endpoints in the collection.
+* Once you get the `access_token` response, you are ready to call the rest of the API endpoints in the collection.
+* Invoke the respective core APIs to fetch accounts, transactions etc.
diff --git a/content/en/docs/Validation/troubleshooting.md b/content/en/docs/Validation/troubleshooting.md
deleted file mode 100644
index 58299eac..00000000
--- a/content/en/docs/Validation/troubleshooting.md
+++ /dev/null
@@ -1,102 +0,0 @@
----
-title: "Troubleshooting"
-linkTitle: "Troubleshooting"
-weight: 10
-date: 2021-09-02
----
-Find useful logs, enable debug options, and connect to UIs to help identify the root cause of errors.
-
-## Debug API traffic
-
-Every time you get an unexpected response from one of the solution APIs, you can check the traffic details to understand the return code or message that was provided.
-
-### Enable debug and full data log on the API endpoint listener
-
-First, enable debug and the full data log on the API endpoint listener to troubleshoot and debug API traffic.
-
-1. Login to the API Gateway Manager user interface.
-2. Navigate to Settings - Dynamic.
-3. Select the corresponding API listener. In most cases, it is "API Manager Traffic."
-4. Select the underlying internal port, just below the API listener.
-5. Select all options in **Override settings for the port**, and then select DATA for the **Trace level** for this port.
-![api-gateway-manager-debug](/Images/api-gateway-manager-debug.png)
-6. Click **Apply**.
-
-### Identify the call in the traffic
-
-Second, run your test again and identify the call in the traffic to troubleshoot and debug API traffic.
-
-1. Navigate to Traffic - HTTP.
-![api-gateway-manager-debug](/Images/api-gateway-manager-traffic-list.png)
-2. Click the method you want to troubleshoot to open the details.
-3. The first section details the execution path.
-![api-gateway-manager-debug](/Images/api-gateway-manager-traffic-execution-path.png)
-You can identify the execution path, the policy used, and where some filter failed. According to the API configuration in API Manager, you will see one or several API policies executed. This could be Inbound Security Policy, Request Policy, Routing Policy, Response Policy, or Fault Handler Policy. Find our more about this policy configuration in [API Manager documentation - custom policies](https://docs.axway.com/bundle/axway-open-docs/page/docs/apim_administration/apimgr_admin/api_mgmt_custom_policies/index.html).
-4. The next sections provide all internal or external requests and responses, with header and body, that are involved in this API call.
-![api-gateway-manager-debug](/Images/api-gateway-manager-traffic-requests.png)
-You can investigate the intermediate request parameters and responses to better understand the current behavior.
-5. The last section provides the execution text trace of every step of the policies execution.
-![api-gateway-manager-debug](/Images/api-gateway-manager-traffic-trace.png)
-You can search for the word "error" or the error message you saw previously to see it in the trace context. Also, you can find more detailed error messages that can help you to fully understand the root cause.
-
-### Take action to fix the issue
-
-Once analyzed, you might take one or several actions to fix the issue:
-
-* Fix a remote backend or cloud service that was not available.
-* Fix client configuration to call the API differently.
-* Fix the Authorization server configuration. Refer to [Cloudentity workspace administration](https://cloudentity.com/developers/howtos/).
-* Fix the API Manager configuration. Refer to [API Management](/docs/configuration/api-management#api-management).
-* Fix the API Gateway KPS configuration. Refer to [KPS configuration](/docs/configuration/api-management/#key-properties-store-kps-configuration).
-* Update a certification configuration. Refer to [API Policies](/docs/configuration/api-management#api-policies).
-
-### Change the log level back to the default
-
-Once solved, make sure to reduce the log level back to default.
-
-## API policy debug
-
-If traffic debug did not help to understand a specific behavior, you can also dive into the policy level.
-
-1. Open *Policy Studio*.
-2. Select **New project from an API Gateway instance**.
-3. Provide a project name for the local copy of the remote instance.
-4. Provide connection details (`api-gateway-manager.\, 443, admin, password`).
-5. Select the **apimgr** instance.
-6. Click **Finish** and wait for all policies to load.
-![api-gateway-manager-debug](/Images/apim-policy-studio-api-containers.png)
-7. Browse under Policy Container - #AMPLIFY-OB-FDX for FDX deployments or #AMPLIFY-OB for Open Finance Brazil deployments. Or, use the search box to provide the API name.
-8. Double click the API name to open the filter path.
-
-### Review the API filter path
-
-Once you open the filter path for the API, you can do the following:
-
-* Discover every filter details configuration. This may help to understand a specific behavior.
-* Change log level of any filter.
-* Add a trace filter between 2 filters.
-* Test changing the policy.
-
-Any change needs to be published with the *Deploy (F6)* command and select all instances of the current group.
-
-{{% alert title="Note" color="primary" %}} These changes will not be persisted and restart of the pod will reverse your changes.{{% /alert %}}
-
-If you need to change the API Policy configuration more permanently, refer to [Configuration - API Policies](/docs/configuration/api-management#api-policies).
-
-## Cloudentity logs
-
-Cloudentity logs can be accessed at the container standard output. In the Kubernetes cluster:
-
-* Identify the acp-xxxxx-xxx pod name
-
-```bash
-kubectl get pods -n open-banking-cloudentity
-```
-
-* Display the logs:
-
-```bash
-kubectl logs acp-xxxxx-xxx -n open-banking-cloudentity
-```
-
-Use `-f` command option to get help to follow the logs stream.
diff --git a/content/en/docs/deployment/_index.md b/content/en/docs/deployment/_index.md
deleted file mode 100644
index da280c90..00000000
--- a/content/en/docs/deployment/_index.md
+++ /dev/null
@@ -1,7 +0,0 @@
----
-title: "Deployment"
-linkTitle: "Deployment"
-weight: 4
----
-
-This section details installing and upgrading the Amplify Open Banking solution.
\ No newline at end of file
diff --git a/content/en/docs/deployment/installation/API-Management/_index.md b/content/en/docs/deployment/installation/API-Management/_index.md
deleted file mode 100644
index 666404a9..00000000
--- a/content/en/docs/deployment/installation/API-Management/_index.md
+++ /dev/null
@@ -1,55 +0,0 @@
----
-title: "API Management Installation"
-linkTitle: "API Management"
-weight: 3
----
-Install API Management for the Amplify Open Banking solution. This guide should be used in conjunction with [Helm Deployment](https://docs.axway.com/bundle/axway-open-docs/page/docs/apim_installation/apigw_containers/deployment_flows/axway_image_deployment/helm_deployment/index.html) instructions for API Gateway installation.
-
-## Deploy a Cassandra cluster
-
-Follow the Cassandra deployment steps outlined in [Deploy a Cassandra cluster](https://docs.axway.com/bundle/axway-open-docs/page/docs/apim_installation/apigw_containers/deployment_flows/axway_image_deployment/helm_deployment/index.html#deploy-a-cassandra-cluster).
-
-## Fetch the Helm chart to examine the values file
-
-Run a `helm fetch` command on the added repository to view the Helm `values.yaml` file:
-
-* For FDX deployment, to fetch helm chart:
-
- ```bash
- helm fetch axway/open-banking-fdx-apim --untar
- ```
-
- This command creates a directory `open-banking-fdx-apim` containing the complete chart, including the `values.yaml` file.
-
-* For Open Finance Brazil deployment, to fetch helm chart:
-
- ```bash
- helm fetch axway/open-banking-obb-apigateway --untar
- ```
-
- This command creates a directory `open-banking-obb-apigateway` containing the complete chart, including the `values.yaml` file.
-
-## Create a customized values.yaml file
-
-Create a customized `values` file, for example, `myvalues.yaml`, and make your customizations. This file should contain only the sections of the `values.yaml` file that you wish to override. Any values not present in the customized file will be picked up from the original `values.yaml` file.
-
-Additional details about customizing values.yaml are available at [Create a customized values.yaml file](https://docs.axway.com/bundle/axway-open-docs/page/docs/apim_installation/apigw_containers/deployment_flows/axway_image_deployment/helm_deployment/index.html#create-a-customized-valuesyaml-file).
-
-### Open Banking parameters
-
-The following parameters are required for any openbanking deployment.
-
-| Value | Description | Default value |
-|:------------- |:------------------------------------- |:-------------- |
-| openbanking.enabled | Enable or disable openbanking deployment | true |
-| openbanking.standard | Set the Open Banking specification or standard | FDX |
-
-### Sample customized values file
-
-Click [openbanking_sample_values.yaml](/samples/apimanagement/openbanking_sample_values.yaml) to download an example of a customized `myvalues.yaml` file.
-
-### Install API Gateway using your customized YAML file
-
-To install API Gateway using your customized YAML file, follow the installation instructions from [Install API Gateway using your customized YAML file](https://docs.axway.com/bundle/axway-open-docs/page/docs/apim_installation/apigw_containers/deployment_flows/axway_image_deployment/helm_deployment/index.html#install-api-gateway-using-your-customized-yaml-file).
-
-When installation is finished, go to the instructions in the subsections below for more details on particular deployments.
diff --git a/content/en/docs/deployment/installation/API-Management/fdx-apim.md b/content/en/docs/deployment/installation/API-Management/fdx-apim.md
deleted file mode 100644
index 171f8c2c..00000000
--- a/content/en/docs/deployment/installation/API-Management/fdx-apim.md
+++ /dev/null
@@ -1,171 +0,0 @@
----
-title: "FDX API Management Configuration"
-linkTitle: "FDX API Management"
-weight: 1
----
-## Configure API Gateway
-
-Once installation is complete, following the instructions at [Install API Gateway using your customized YAML file](https://docs.axway.com/bundle/axway-open-docs/page/docs/apim_installation/apigw_containers/deployment_flows/axway_image_deployment/helm_deployment/index.html#install-api-gateway-using-your-customized-yaml-file), and mount the FDX policies and configuration files using the below steps.
-
-### Download the API Gateway configuration files
-
-To download the Amplify Open Banking API Management configuration package for FDX deployment, go to [Axway Repository](https://repository.axway.com/), and search for “Amplify Open Banking”, then check the `Utility` box. Then download the `apigateway-config-fdx-7.7.0.20xxxxxx-BNxx.tar.gz` file.
-
-After the download is finished, extract the archive's contents.
-
-```bash
-tar -xzf apigateway-config-fdx-7.7.0.20xxxxxx-BNxx.tar.gz
-```
-
-This command creates a directory `apigateway-config-fdx-7.7.0.20xxxxxx-BNxx` containing following sub-directories and files.
-
-```
-apigateway-config-fdx-7.7.0.20xxxxxx-BNxx
-├── PS-Projects
-│ └── FDX-YAML #directory containing policy configuration in YAML format
-├── README.md
-├── merge #merge directory containing API Gateway configuration files
-│ ├── apigateway
-│ └── mandatoryFiles
-└── sample #sample scripts
- ├── kps_import.sh #deploy YAML config and merge dir
- └── mount_config.sh #import KPS configuration
-```
-
-`PS-Projects/FDX-YAML` directory contains the policies created using [YAML configuration](https://docs.axway.com/bundle/axway-open-docs/page/docs/apim_yamles/index.html).
-
-### Prepare values.yaml for the deployment
-
-As some of the variables are defined in `PS-Projects/FDX-YAML/values.yaml` file, you must update it before deployment. it is recommendation to copy the `PS-Projects/FDX-YAML/values.yaml` to `local_values/FDX-YAML/values.yaml` and then make changes in it.
-
-```bash
-cp apigateway-config-fdx-7.7.0.20xxxxxx-BNxx/PS-Projects/FDX-YAML/values.yaml local_values/FDX-YAML/values.yaml
-```
-
-The following parameters are required for FDX deployment, so update the `local_values/FDX-YAML/values.yaml` file.
-
-| Value | Description | Default value | Example |
-|:------------- |:------------------------------------- |:-------------- |:--------|
-| Environment_Configuration.Service.ACP_Host.name | Host on which Cloudentity is running. | acp.open-banking-cloudentity | |
-| Environment_Configuration.Service.ACP_Host.port | Port where Cloudentity is running. | 8443 | |
-| Environment_Configuration.Service.apimgr.name | Endpoint where API Manager is running. | api-manager-host | api-manager.open-banking.axway.com |
-| Environment_Configuration.Service.apimgr.port | Post at which API Manager is running. | 443 | |
-| Policies._AMPLIFY_OB_FDX.Mock.Login_Page.PAGE_login.Set_var_demo_apps_enabled.attributeValue | Set to `true` if demo-apps are deployed. | false | |
-| Policies._AMPLIFY_OB_FDX.Mock.Login_Page.PAGE_login.Set_demo_apps_url.attributeValue | Endpoint where demo apps are running. If not deploying demo apps component then keep the default. | `https://demo-apps.\` | `https://demo-apps.open-banking.axway.com` |
-
-### Mount the FDX Configuration
-
-Make sure that API Gateway pods (i.e., anm, apimgr, apitraffic) are in running state and then execute the following commands:
-
-```bash
-cd apigateway-config-fdx-7.7.0.20xxxxxx-BNxx/sample
-./mount_config.sh -p FDX
-cd -
-```
-
-The above script deploys YAML archive and other configuration files from `merge` directory to `gw-external-config` volume mount in K8S cluster. Before building the YAML archive, it replaces `apigateway-config-fdx-7.7.0.20xxxxxx-BNxx/PS-Projects/FDX-YAML/values.yaml` with `local_values/FDX-YAML/values.yaml`, which contains the actual values for the target environment.
-
-## Configure API Manager
-
-To configure API Manager (i.e., to create Organizations, APIs, applications and import KPS data), use the `open-banking-fdx-apim-config` helm chart. During installation it creates Organizations, sample applications and FDX APIs. It also imports data in the KPS tables.
-
-### Change apiadmin user password
-
-Log in to the API Manager UI to change the default password of `apiadmin` user. It is required for successful execution of the below steps.
-
-### Fetch the Helm chart to examine the values file
-
-Run a `helm fetch` command on the added repository to view the Helm `values.yaml` file:
-
-```bash
-helm fetch axway/open-banking-fdx-apim-config --untar
-```
-
-This command creates a directory `open-banking-fdx-apim-config` containing the complete chart, including the `values.yaml` file.
-
-### Customize the APIM configuration Helm chart
-
-Customize the `open-banking-fdx-apim-config/values.yaml` file as follows.
-
-| Value | Description | Default value |
-|:------------- |:------------------------------------- |:-------------- |
-| global.domainName | Set the domainname for all ingress. | None |
-| global.env | Set the default environment. | prod |
-| global.dockerRegistry.url | URL for the docker registry. | None |
-| global.dockerRegistry.username | Login name to pull Docker images from the Axway Repository. | None |
-| global.dockerRegistry.token | Password token to pull Docker images from the Axway Repository. | None |
-| anm.admin.username | API Gateway admin username | admin |
-| anm.admin.password | API Gateway admin password | |
-| apimgr.admin.username | API Manager admin username | apiadmin |
-| apimgr.admin.password | API Manager admin password | |
-| demoapp.bankio.clientId | The bankio demo apps client id. | bankio |
-| demoapp.postman.clientId | The postman client id. | postman |
-
-### Install the APIM configuration Helm chart
-
-1. Run the following command to install the APIM config Helm chart:
-
- ```bash
- helm install apim-config open-banking-fdx-apim-config -n open-banking-apim
- ```
-
-2. Check that the status of the Helm command is deployed:
-
- ```
- NAME: apim-config
- LAST DEPLOYED:
- NAMESPACE: open-banking-apim
- STATUS: deployed
- REVISION: 1
- TEST SUITE: None
- ```
-
-### Verify the APIM configuration Helm chart deployment
-
-1. Wait a few minutes and use the following commands to check the deployment status.
-
- ```bash
- kubectl get pods -n open-banking-apim
- ```
-
-2. Verify that:
- * **jobs** with name import-api-27983c3f-xxx are **Completed**:
-
- ```
- NAME READY STATUS RESTARTS
- anm-6d86b7dfbd-4wbnx 1/1 Running 0
- apimgr-544b55fffb-qsn87 1/1 Running 0
- import-api-27983c3f-... 0/1 Completed 0
- traffic-5d986c7d55-cv6dv 1/1 Running 0
- ```
-
-3. Check API Manager `https://api-manager.`:
- * Refresh or log in again.
- * Make sure that Open Banking APIs are in the API Catalog.
- * Make sure that Default apps are in Client applications.
-
-4. Check KPS data in API Gateway Manager `https://api-gateway-manager.`:
- * Log in and go to *Settings - Key Property Stores*.
- * Make sure that `Configuration` and `Error` tables are not emplty.
-
-## Post deployment
-
-This post deployment step is only applicable if you have changed the default ports, client ids, client secrets, etc. during the [Cloudentity](/docs/deployment/installation/cloudentity/acp) or [Consent Apps](/docs/deployment/installation/cloudentity/consent-apps) deployment.
-
-### Update KPS configuration
-
-To update configurations in the `cfg` KPS table:
-
-1. Get the KPS configuration table data file from the Helm chart:
- * Configuration table KPS data file is `open-banking-fdx-apim-config/files/kps/amplify_configuration.json`.
- * Update it with the values specific to your deployment.
-
-2. You can use the sample script `kps_import.sh` provided in `apigateway-config-fdx-7.7.0.20xxxxxx-BNxx.tar.gz` package to import data in KPS. Example usage is:
-
- ```bash
- kps_import.sh -a api-gateway-manager. -i traffic-5dbc49dfd8-6mdnt -f amplify_configuration.json -t cfg -u admin -p password"
- ```
-
-3. Verify the insertion in the KPS table:
- * Log in to the API Gateway Manager UI and go to *Settings - Key Property Stores*.
- * Click on AMPLIFY/Configuration and make sure that the data is updated.
diff --git a/content/en/docs/deployment/installation/API-Management/obb-apim.md b/content/en/docs/deployment/installation/API-Management/obb-apim.md
deleted file mode 100644
index 0f44a76d..00000000
--- a/content/en/docs/deployment/installation/API-Management/obb-apim.md
+++ /dev/null
@@ -1,165 +0,0 @@
----
-title: "Open Finance Brazil API Management Configuration"
-linkTitle: "Open Finance Brazil API Management"
-weight: 2
----
-
-## Configure API Gateway
-
-Once the installation is complete following the instructions at [Install API Gateway using your customized YAML file](https://docs.axway.com/bundle/axway-open-docs/page/docs/apim_installation/apigw_containers/deployment_flows/axway_image_deployment/helm_deployment/index.html#install-api-gateway-using-your-customized-yaml-file), mount the FDX policies and configuration files using the below steps.
-
-### Download the API Gateway configuration files
-
-To download the Amplify Open Banking API Management configuration package for OBB deployment, go to [Axway Repository](https://repository.axway.com/) and search for “Amplify Open Banking.” Check the `Utility` box and download the `apigateway-config-obb-7.7.0.20xxxxxx-BNxx.tar.gz` file.
-
-After the download is finished, extract the archive's contents:
-
-```bash
-tar -xzf apigateway-config-obb-7.7.0.20xxxxxx-BNxx.tar.gz
-```
-
-This command creates a directory `apigateway-config-obb-7.7.0.20xxxxxx-BNxx` containing the following sub-directories and files:
-
-```
-apigateway-config-obb-7.7.0.20xxxxxx-BNxx
-├── PS-Projects
-│ └── OBB-YAML #directory containing policy configuration in YAML format
-├── README.md
-├── merge #merge directory containing API Gateway configuration files
-│ ├── apigateway
-│ └── mandatoryFiles
-└── sample #sample scripts
- └── mount_config.sh #import KPS configuration
-```
-
-`PS-Projects/OBB-YAML` directory contains the policies created using [YAML configuration](https://docs.axway.com/bundle/axway-open-docs/page/docs/apim_yamles/index.html).
-
-### Prepare values.yaml for the deployment
-
-As some of the variables are defined in the `PS-Projects/OBB-YAML/values.yaml` file, you must update it before deployment. It is recommended to copy the `PS-Projects/OBB-YAML/values.yaml` to `local_values/OBB-YAML/values.yaml` and then make changes in it.
-
-```bash
-cp apigateway-config-obb-7.7.0.20xxxxxx-BNxx/PS-Projects/OBB-YAML/values.yaml local_values/OBB-YAML/values.yaml
-```
-
-### Mount the OBB Configuration
-
-Make sure that API Gateway pods (i.e. anm, apimgr, apitraffic) are in running state and then execute the following commands:
-
-```bash
-cd apigateway-config-obb-7.7.0.20xxxxxx-BNxx/sample
-./mount_config.sh -p OBB
-cd -
-```
-
-The above script deploys YAML archive and other configuration files from `merge` directory to `gw-external-config` volume mount in K8S cluster. Before building the YAML archive it replaces `apigateway-config-obb-7.7.0.20xxxxxx-BNxx/PS-Projects/OBB-YAML/values.yaml` with `local_values/OBB-YAML/values.yaml`, which contains the actual values for the target environment.
-
-## Configure API Manager
-
-To configure API Manager (i.e. to create Organizations, APIs, applications and import KPS data), use the `open-banking-apim-config` helm chart. During installation it creates Organizations, sample applications and OBB APIs. It also imports data in the KPS tables.
-
-### Change apiadmin user password
-
-Log in to the API Manager UI to change the default password of `apiadmin` user. It is required for the successful execution of the below steps.
-
-### Fetch the Helm chart to examine the values file
-
-Run a `helm fetch` command on the added repository to view the Helm `values.yaml` file:
-
-```bash
-helm fetch axway/open-banking-apim-config --untar
-```
-
-This command creates a directory `open-banking-apim-config` containing the complete chart, including the `values.yaml` file.
-
-### Customize the APIM configuration Helm chart
-
-Customize the `open-banking-apim-config/values.yaml` file as follows:
-
-| Value | Description | Default value |
-|:------------- |:------------------------------------- |:-------------- |
-| global.domainName | Set the domainname for all ingress. | None |
-| global.env | Set the default environment. | prod |
-| global.dockerRegistry.url | URL for the docker registry. | None |
-| global.dockerRegistry.username | Login name to pull Docker images from the Axway Repository. | None |
-| global.dockerRegistry.token | Password token to pull Docker images from the Axway Repository. | None |
-| anm.admin.username | API Gateway admin username. | admin |
-| anm.admin.password | API Gateway admin password. | |
-| apimgr.admin.username | API Manager admin username. | apiadmin |
-| apimgr.admin.password | API Manager admin password. | |
-| demoapp.bankio.clientId | The bankio demo apps client id. | bankio |
-| demoapp.postman.clientId | The postman client id. | postman |
-
-### Install the APIM configuration Helm chart
-
-1. Run the following command to install the APIM config Helm chart:
-
- ```bash
- helm install apim-config open-banking-apim-config -n open-banking-apim
- ```
-
-2. Check that the status of the Helm command is deployed:
-
- ```
- NAME: apim-config
- LAST DEPLOYED:
- NAMESPACE: open-banking-apim
- STATUS: deployed
- REVISION: 1
- TEST SUITE: None
- ```
-
-### Verify the APIM configuration Helm chart deployment
-
-1. Wait a few minutes and use the following commands to check the deployment status:
-
- ```bash
- kubectl get pods -n open-banking-apim
- ```
-
-2. Verify that:
- * **jobs** with name import-api-27983c3f-xxx are **Completed**:
-
- ```
- NAME READY STATUS RESTARTS
- anm-6d86b7dfbd-4wbnx 1/1 Running 0
- apimgr-544b55fffb-qsn87 1/1 Running 0
- import-api-27983c3f-... 0/1 Completed 0
- traffic-5d986c7d55-cv6dv 1/1 Running 0
- ```
-
-3. Check API Manager `https://api-manager.`:
- * Refresh or log in again.
- * Make sure that Open Banking APIs are in the API Catalog.
- * Make sure that Default apps are in Client applications.
-
-## Post deployment
-
-### Update KPS configuration
-
-Fetch the new kps-config module
-
-```bash
-helm fetch axway/open-banking-obb-kps-config --untar
-```
-
-This command creates a directory `open-banking-obb-kps-config` containing the complete chart, including the `values.yaml` file.
-
-### Customize the KPS Config Helm chart
-
-Customize the `open-banking-obb-kps-config/values.yaml` file as follows.
-
-| Value | Description | Default value |
-|:------------- |:------------------------------------- |:-------------- |
-| gateway.user | The Gateway Manager user. | `admin` |
-| gateway.password | The Gateway manager password. | `changeme` |
-| gateway.name | The deployment name. | `open-banking-gateway` |
-| gateway.ingress | The Gateway Manager URL. | `api-gateway-manager.` |
-| gateway.apimPodName | APIM Pod name. | `apim-apimanager-` |
-| kps.env.config | KPS Configuration | Typically won't change |
-
-Verify the insertion in the KPS table:
-
-* Log into the API Gateway Manager UI and go to *Settings - Key Property Stores*.
-* Click on AMPLIFY/Configuration.
-* Check that the table is not empty. Click on table rows to chech details.
diff --git a/content/en/docs/deployment/installation/Cloudentity/_index.md b/content/en/docs/deployment/installation/Cloudentity/_index.md
deleted file mode 100644
index adfc4444..00000000
--- a/content/en/docs/deployment/installation/Cloudentity/_index.md
+++ /dev/null
@@ -1,27 +0,0 @@
----
-title: "Cloudentity Installation"
-linkTitle: "Cloudentity"
-weight: 20
----
-
-Install Cloudentity for the Amplify Open Banking solution. Cloudentity component provides Identity and Access Management along with consent management.
-
-Cloudentity includes 2 components:
-
-* Cloudentity
-* Sample Consent Applications
-
-{{% alert title="Note" color="primary" %}} Sample Consent applications are not developed for production usage. For more information please see deatils in [Component View](/docs/overview/technical/component).{{% /alert %}}
-
-## Fetch the Cloudentity Helm charts
-
-Fetch the Amplify Open Banking Cloudentity Helm charts to view the `values.yaml` file.
-
-```bash
-helm fetch axway/open-banking-cloudentity --untar
-helm fetch axway/open-banking-consent-apps --untar
-```
-
-You should get `open-banking-cloudentity` and `open-banking-consent-apps` local folders.
-
-For each component, follow the instructions in the subsections below.
diff --git a/content/en/docs/deployment/installation/Cloudentity/acp.md b/content/en/docs/deployment/installation/Cloudentity/acp.md
deleted file mode 100644
index 5f1d93bf..00000000
--- a/content/en/docs/deployment/installation/Cloudentity/acp.md
+++ /dev/null
@@ -1,114 +0,0 @@
----
-title: "Cloudentity Installation"
-linkTitle: "Cloudentity"
-weight: 1
----
-
-Install Cloudentity for the Amplify Open Banking solution.
-
-## Create a customized values.yaml file
-
-Find the namespace of the cert-manager component.
-
-```bash
-kubectl get pods -A | grep cert-manager | awk '{print $1}' | uniq
-```
-
-Create a customized `values` file, for example, `myvalues.yaml`, and make your customizations. This file should contain only the sections of the `values.yaml` file that you wish to override. Any values not present in the customized file will be picked up from the original `values.yaml` file.
-
-| Value | Description | Default value |
-|:------------- |:------------------------------------- |:-------------- |
-| global.dockerRegistry.username | Defining Cloudentity repository username. | None |
-| global.dockerRegistry.password | Defining Cloudentity repository password. | None |
-| acp-prereq.cert.internal.certManager | Define if cert-manager is used internally. False is currently not supported. | true |
-| acp-prereq.cert.internal.certManagerNamespace | Namespace where cert-manager is installed. Use the result of the previous command. | None |
-| acp-prereq.cert.ingress.certManager | Define if cert-manager is used externally. If set to false, define cert and keys with values below. | true |
-| acp-prereq.cert.ingress.cert | Use specific cert. It can be a wildcard. Must be defined only if certManager is set to false. | None |
-| acp-prereq.cert.ingress.key | Use specific key. It can be a wildcard. Must be defined only if certManager is set to false. | None |
-| acp-prereq.cert.ingress.certMtls | Use specific cert for Cloudentity mtls endpoint. It can be a wildcard. Must be defined only if certManager is set to false. | None |
-| acp-prereq.cert.ingress.keyMtls | Use specific key for Cloudentity mtls endpoint. It can be a wildcard. Must be defined only if certManager is set to false. | None |
-| acp.serverURL | Cloudentity admin server URL. | None |
-| acp.serverURLMtls | Cloudentity mtls server URL. | None |
-| acp.secretConfig.data.redis.password | redis password. | None |
-| acp.ingress.tls.hosts | Cloudentity admin server URL. | None |
-| acp.ingress.hosts.host | Cloudentity admin server URL. | None |
-| acp.ingressMtls.tls.hosts | Cloudentity mtls server URL. | None |
-| acp.ingressMtls.hosts.host | Cloudentity mtls server URL. | None |
-| acp.features.swagger_ui | Enable swagger UI. | true |
-| acp.features.fdx_dcr | Enable FDX DCR endpoint. | true |
-| acp.config.data.storage.audit_events.retention.enabled | Enable audit events retention. | true |
-| acp.config.data.storage.audit_events.retention.batch_limit | Audit events retention batch delete limit. | 1000 |
-| acp.config.data.storage.audit_events.retention.max_age | Remove audit events older than max age limit. | 6h0m0s |
-| acp.config.data.server.obbr_base_paths | Open banking Brasil API base path whitelist. | None |
-| redis-cluster.password | Defining Cloudentity's Redis password. | None |
-
-Remove the following lines if cert-manager is not used for ingress:
-
-```yaml
-cert-manager.io/cluster-issuer: letsencrypt-prod (l22)
-cert-manager.io/acme-challenge-type: http01 (l23)
-```
-
-## Prepare deployment
-
-Create the target namespace on the cluster:
-
-```bash
-kubectl create namespace open-banking-cloudentity
-```
-
-## Install the Cloudentity Helm chart
-
-1. Deploy the Cloudentity Helm chart:
- ```bash
- helm install acp -n open-banking-cloudentity -f myvalues.yaml axway/open-banking-cloudentity
- ```
-
-2. Check that the status of the Helm command is deployed:
-
- ```
- NAME: acp
- LAST DEPLOYED:
- NAMESPACE: open-banking-cloudentity
- STATUS: deployed
- REVISION: 1
- TEST SUITE: None
- ```
-
-## Verify the Cloudentity Helm chart deployment
-
-1. Wait a few minutes and use the following commands to check the deployment status.
-
- ```
- kubectl get pods -n open-banking-cloudentity
- ```
-
-2. Verify that:
- * **pods** with acp-xxx-xxx, name acp-cockroachdb-xxx, acp-redis-cluster-x are all **Running**.
- * **pods** with acp-cockroachdb-init-xxx is **Completed**.
-
- ```
- NAME READY STATUS RESTARTS AGE
- acp-66d8797fb4-njbw6 1/1 Running 0 3m
- acp-cockroachdb-0 1/1 Running 0 3m
- acp-cockroachdb-init-h8hdc 0/1 Completed 0 3m
- acp-redis-cluster-0 1/1 Running 0 3m
- acp-redis-cluster-1 1/1 Running 0 3m
- acp-redis-cluster-2 1/1 Running 0 3m
- ```
-
-3. Check ingress with this command:
-
- ```bash
- kubectl get ingress -n open-banking-cloudentity
- ```
-
-4. Verify that this ingress is provisioned. It must have a public ip or a dns value in the ADDRESS column.
-
- ```
- NAME HOSTS ADDRESS PORTS AGE
- acp acp-admin. xxxxxxxxxxxxx.amazonaws.com 80, 443 2m
- acp-mtls acp. xxxxxxxxxxxxx.amazonaws.com 80, 443 2m
- ```
-
-5. Connect to `https://acp-admin.` with admin / admin and change the password immediately.
diff --git a/content/en/docs/deployment/installation/Cloudentity/consent-apps.md b/content/en/docs/deployment/installation/Cloudentity/consent-apps.md
deleted file mode 100644
index 09de3f2d..00000000
--- a/content/en/docs/deployment/installation/Cloudentity/consent-apps.md
+++ /dev/null
@@ -1,118 +0,0 @@
----
-title: "Consent Applications Installation"
-linkTitle: "Consent Applications"
-weight: 2
----
-Install Cloudentity sample consent applications for the Amplify Open Banking solution.
-
-## Create a customized values.yaml file
-
-Create a customized `values` file, for example, `myvalues.yaml`, and make your customizations. This file should contain only the sections of the `values.yaml` file that you wish to override. Any values not present in the customized file will be picked up from the original `values.yaml` file.
-
-| Value | Description | Default value |
-|:------------- |:------------------------------------- |:-------------- |
-| dockerRegistry.username | Axway repo username. | None |
-| dockerRegistry.token | Axway repo token. | None |
-| dockerRegistryCloudentity.username | Cloudentity repo username. | None |
-| dockerRegistryCloudentity.token | Cloudentity repo token. | None |
-| cert.internal.certManager | Define if cert-manager is used internally. False is currently not supported. | true |
-| cert.internal.certManagerNamespace | Namespace where cert-manager is installed. Use the result of the previous command. | None |
-| cert.ingress.certManager | Define if cert-manager is used externally. If set to false, define cert and keys with values below. | true |
-| cert.ingress.wildcard | Define whether the same wildcard certificate is used externally for all ingress. If set to true, define wildcard certificate and its key with cert.ingress.cert/key below. If set to false, define custom certificate and keys with cert.ingress.\.cert/key below. | true |
-| cert.ingress.cert | Use a specific wildcard certificate. Must be defined only if certManager is set to false. | None |
-| cert.ingress.key | Use a specific wildcard key. Must be defined only if certManager is set to false. | None |
-| cert.ingress.consentAdmin.cert | Use a dedicated certificate. Must be defined only if certManager and wildcard are set to false. | None |
-| cert.ingress.consentAdmin.key | Use a dedicated key. Must be defined only if certManager and wildcard are set to false. | None |
-| cert.ingress.consentPage.cert | Use a dedicated certificate. Must be defined only if certManager and wildcard are set to false. | None |
-| cert.ingress.consentPage.key | Use a dedicated key. Must be defined only if certManager and wildcard are set to false. | None |
-| cert.ingress.consentSS.cert | Use a dedicated certificate. Must be defined only if certManager and wildcard are set to false. | None |
-| cert.ingress.consentSS.key | Use a dedicated key. Must be defined only if certManager and wildcard are set to false. | None |
-| openbanking.acpURL | Cloudentity server URL. | None |
-| openbanking.consentPage.ingress.annotations.nginx.ingress.kubernetes.io /proxy-ssl-secret | \/consent-openbanking-consent-page-tls. | open-banking-consent-apps /consent-openbanking-consent-page-tls |
-| openbanking.consentPage.ingress.hosts | Update with the consent page URL. | consent.\ |
-| openbanking.consentPage.ingress.tls.hosts | Update with the consent page URL. | consent.\ |
-| openbanking.consentAdmin.ingress.annotations.nginx.ingress.kubernetes.io /proxy-ssl-secret | \/consent-openbanking-consent-admin-tls. | open-banking-consent-apps /consent-openbanking-consent-admin-tls |
-| openbanking.consentAdmin.ingress.hosts | Update with the consent admin URL. | consent-admin.\ |
-| openbanking.consentAdmin.ingress.tls.hosts | Update with the consent admin URL. | consent-admin.\ |
-| openbanking.consentSelfservice.ingress.annotations.nginx.ingress.kubernetes.io /proxy-ssl-secret | \/consent-openbanking-consent-self-service-tls. | open-banking-consent-apps /consent-openbanking-consent-self-service-tls |
-| openbanking.consentSelfservice.ingress.hosts | Update with the consent Self service URL. | consent-selfservice.\ |
-| openbanking.consentSelfservice.ingress.tls.hosts | Update with the consent Self service URL. | consent-selfservice.\ |
-| openbanking.import.enabled | To import the default configuration for Open Finance Brazil or FDX deployment. Set to true for installation and then keep it false for upgrades. | false |
-| openbanking.import.variables.consent_self_service_portal_url | Update with the consent self service portal url. | `https://consent-selfservice.` |
-| openbanking.import.variables.consent_admin_portal_url | Update with the consent admin portal url. | `https://consent-admin.` |
-| openbanking.import.variables.consent_page_url | Update with the consent page url. | `https://consent.` |
-| openbanking.import.variables.developer_tpp_url | Update with the developer tpp url.| `https://financroo.` |
-| openbanking.import.variables.postman_client_id | Update with the Postman client id. | postman-eks |
-| openbanking.import.variables.bank_io_client_id | Update with the Bank.io client id. | bankio-eks |
-| openbanking.import.variables.bank_io_redirect_uri | Update with the bank.io redirect url. | `https://services-api./login` |
-| openbanking.import.variables. dcr_jwks_uri | Openbanking central directory jwks info. | OBB Sandbox |
-| openbanking.import.variables.organization_id | Bank Organization ID registered at Central Directory. | None |
-| openbanking.import.variables.first_tpp_redirect_uri | Sample TPP1 used. | None |
-| openbanking.import.variables.second_tpp_redirect_uri | Sample TPP1 used. | None |
-
-## Prepare deployment
-
-Create the target namespace on the cluster:
-
-```bash
-kubectl create namespace open-banking-consent-apps
-```
-
-## Install the Consent Apps Helm chart
-
-1. Deploy the Consent Apps Helm chart from the Axway repository.
-
- ```bash
- helm install consent-apps -n open-banking-consent-apps open-banking-consent-apps -f myvalues.yaml
- ```
-
-2. Check that the status of the Helm command is deployed:
-
- ```
- NAME: consent-apps
- LAST DEPLOYED:
- NAMESPACE: open-banking-consent-apps
- STATUS: deployed
- REVISION: 1
- TEST SUITE: None
- ```
-
-## Verify the Consent Helm chart deployment
-
-1. Wait a few minutes and use the following commands to check the deployment status.
-
- ```
- kubectl get pods -n open-banking-consent-apps
- ```
-
-2. Verify that:
- * **pods** with consent-openbanking-bank-xxxx-xxx, consent-openbanking-consent-admin-xxxx-xxx, consent-openbanking-consent-page-xxxx-xxx, consent-openbanking-consent-self-service-xxxx-xx are **Running** and Restart is **0**.
- * **pods** with consent-openbanking-import-xxx is **Completed** and Restart is **0**.
-
- ```
- NAME READY STATUS RESTARTS
- consent-openbanking-bank-xxxx-xxx 1/1 Running 0
- consent-openbanking-consent-admin-xxxx-xxx 1/1 Running 0
- consent-openbanking-consent-page-xxxx-xxx 1/1 Running 0
- consent-openbanking-consent-self-service-xxxx-xxx 1/1 Running 0
- consent-openbanking-import-xxx 0/1 Completed 0
- ```
-
-3. Check ingress with this command:
-
- ```bash
- kubectl get ingress -n open-banking-consent-apps
- ```
-
-4. Verify that these ingresses are provisioned. They must have a public ip or a dns value in the ADDRESS column.
-
- ```
- NAME HOSTS ADDRESS PORTS AGE
- consent-openbanking-consent-admin consent-admin. xxxxxxxxxxxxx.amazonaws.com 80, 443 2m
- consent-openbanking-consent-page consent. xxxxxxxxxxxxx.amazonaws.com 80, 443 2m
- consent-openbanking-consent-self-service consent-selfservice. xxxxxxxxxxxxx.amazonaws.com 80, 443 2m
- ```
-
-## Post Deployment
-
-* Navigate to Openbanking workspace, Settings - Authorization - Trusted client certificates, and update the Trusted client certificates content with the `open-banking-consent-apps/files/cert.pem` file attached.
diff --git a/content/en/docs/deployment/installation/_index.md b/content/en/docs/deployment/installation/_index.md
deleted file mode 100644
index badda2bc..00000000
--- a/content/en/docs/deployment/installation/_index.md
+++ /dev/null
@@ -1,32 +0,0 @@
----
-title: "Installation"
-linkTitle: "Installation"
-weight: 2
----
-
-This guide describes how to install the Amplify Open Banking solution.
-
-## Connect to the Axway Repository
-
-You must have a [service account](https://docs.axway.com/bundle/platform-management/page/docs/management_guide/organizations/managing_organizations/managing_service_accounts/index.html) with Axway in order to access the Helm chart and public images.
-
-### Access the Helm chart
-
-To access the Amplify Open Banking Helm charts, go to [Axway Repository](https://repository.axway.com/), and search for “Amplify Open Banking”, then check the helm chart box. The chart can be used directly from the repository, but you must fetch the chart first to see the `values.yaml` file.
-
-### Add the Axway Helm repository
-
-Add the helm repository:
-
-```bash
-helm repo add axway https://helm.repository.axway.com --username= --password=
-```
-
-Once the registry is added, make sure you can see the open-banking packages:
-
-```bash
-helm repo update
-helm search repo axway
-```
-
-For each component, follow the install instructions.
diff --git a/content/en/docs/deployment/installation/agents.md b/content/en/docs/deployment/installation/agents.md
deleted file mode 100644
index 62cfe33e..00000000
--- a/content/en/docs/deployment/installation/agents.md
+++ /dev/null
@@ -1,22 +0,0 @@
----
-title: "Amplify Agents Installation"
-linkTitle: "Amplify Agents"
-weight: 15
----
-Install Amplify Agents, discovery and traceability agents, for the Amplify Open Banking solution. For detailed installation instructions, see [Connect API Manager](https://docs.axway.com/bundle/amplify-central/page/docs/connect_manage_environ/connect_api_manager/index.html).
-
-Also make sure that you configure discovery agent with IdP. For the detailed information, see [Provisioning OAuth credential to an identity provider](https://docs.axway.com/bundle/amplify-central/page/docs/connect_manage_environ/marketplace_provisioning/index.html#provisioning-oauth-credential-to-an-identity-provider).
-
-You can also use the following sample discovery agent IdP configuration for Amplify Open Banking Deployment:
-
-```console
-AGENTFEATURES_IDP_NAME_1: "Cloudentity"
-AGENTFEATURES_IDP_TYPE_1: "generic"
-AGENTFEATURES_IDP_METADATAURL_1: ""
-AGENTFEATURES_IDP_AUTH_TYPE_1: "tls_client_auth"
-AGENTFEATURES_IDP_AUTH_CLIENTID_1: "string"
-AGENTFEATURES_IDP_SSL_ROOTCACERTPATH_1: /tls/ca.crt
-AGENTFEATURES_IDP_SSL_CLIENTCERTPATH_1: /tls/client.crt
-AGENTFEATURES_IDP_SSL_CLIENTKEYPATH_1: /tls/client.key
-AGENTFEATURES_IDP_AUTH_USECACHEDTOKEN_1: "false"
-```
diff --git a/content/en/docs/deployment/installation/backend-services.md b/content/en/docs/deployment/installation/backend-services.md
deleted file mode 100644
index 6c9d2279..00000000
--- a/content/en/docs/deployment/installation/backend-services.md
+++ /dev/null
@@ -1,154 +0,0 @@
----
-title: "Backend Services Installation"
-linkTitle: "Backend Services"
-weight: 25
----
-Install Backend Services for the Amplify Open Banking solution.
-
-## Financial Data Exchange (FDX) deployments
-
-Fetch the Amplify Open Banking Backend Services Helm chart to view the `values.yaml` file.
-
-```bash
-helm fetch axway/open-banking-fdx-backend --untar
-```
-
-You should get an `open-banking-fdx-backend` local folder.
-
-### Customize the Backend Services Helm chart
-
-Customize the `values.yaml` file as follows.
-
-| Value | Description | Default value |
-|:------------- |:------------------------------------- |:-------------- |
-| global.dockerRegistry.username | Login name to pull Docker images from the Axway Repository. | None |
-| global.dockerRegistry.token | Password token to pull Docker images from the Axway Repository. | None |
-| global.apihost | MTLS apigateway endpoint. | `https://mtls-api-proxy./open-banking` |
-| mysqldb.dbname | Mock backend database name. | *fdxmockbackend* |
-| mysqldb.dbuser | Mock backend database username. | *mockbank* |
-| secrets.MYSQL_ROOT_PASSWORD | Mock backend database root password. | None|
-| secrets.MYSQL_USER_PASSWORD | Mock backend database user password. | None |
-| *apiname*.enable | To enable or disable the API deployment. | true |
-
-### Install the Backend Services Helm chart
-
-1. Create the target namespace on the cluster:
-
- ```bash
- kubectl create namespace open-banking-backend
- ```
-
-2. Install the Backend Services Helm chart:
-
- ```bash
- helm install backend open-banking-fdx-backend -n open-banking-backend
- ```
-
-3. Check that the status of the Helm command is deployed:
-
- ```bash
- NAME: backend
- LAST DEPLOYED:
- NAMESPACE: open-banking-backend
- STATUS: deployed
- REVISION: 1
- TEST SUITE: None
- ```
-
-### Verify the Backend Services Helm chart deployment
-
-1. Wait a few minutes and use the following commands to check the deployment status.
-
- ```
- kubectl get pods -n open-banking-backend
- ```
-
-2. Verify that:
-
- * **pods** with name mysqldb-xxx-xx and those name after the api names are all **Running** and Restart is **0**.
-
- ```
- NAME READY STATUS RESTARTS AGE
- fdxcore-xxx-xx 1/1 Running 0 2m
- fdxmoneymovement-xxx-xx 1/1 Running 0 2m
- fdxtax-xxx-xx 1/1 Running 0 2m
- obieproducts-xxx-xx 1/1 Running 0 2m
- mysqldb-xxx-xx 1/1 Running 0 2m
- ```
-
-## Open Finance Brazil deployments
-
-Fetch the Amplify Open Banking Backend Services Helm chart to view the `values.yaml` file.
-
-```bash
-helm fetch axway/open-banking-backend-chart --untar
-```
-
-You should get an `open-banking-backend-chart` local folder.
-
-### Customize Backend Services Helm chart
-
-Customize the `values.yaml` file as follows.
-
-| Value | Description | Default value |
-|:------------- |:------------------------------------- |:-------------- |
-| global.dockerRegistry.username | Login name to pull Docker images from the Axway Repository. | None |
-| global.dockerRegistry.token | Password token to pull Docker images from the Axway Repository. | None |
-| global.apihost | MTLS apigateway endpoint. | None |
-| global.apidomain | MTLS apigateway endpoint. | None |
-| mysqldb.dbname | Mock backend database name. | *medicimockbackend* |
-| mysqldb.dbuser | Mock backend database username. | *mockbank* |
-| secrets.MYSQL_ROOT_PASSWORD | Mock backend database root password. | None|
-| secrets.MYSQL_USER_PASSWORD | Mock backend database user password. | None |
-| *apiname*.disable | To disable the API deployment set it to true | false |
-
-### Install Backend Services Helm chart
-
-1. Create the target namespace on the cluster:
-
- ```bash
- kubectl create namespace open-banking-backend
- ```
-
-2. Install the Backend Services Helm chart:
-
- ```bash
- helm install backend-services open-banking-backend-chart -n open-banking-backend
- ```
-
-3. Check that the status of the Helm command is deployed:
-
- ```
- NAME: backend-services
- LAST DEPLOYED:
- NAMESPACE: open-banking-backend
- STATUS: deployed
- REVISION: 1
- TEST SUITE: None
- ```
-
-### Verify Backend Services Helm chart deployment
-
-1. Wait a few minutes and use the following commands to check the deployment status.
-
- ```
- kubectl get pods -n open-banking-backend
- ```
-
-2. Verify that:
-
- * **pods** with name mysqldb-xxx-xx and those name after the api names are all **Running** and Restart is **0**.
-
- ```
- NAME READY STATUS RESTARTS AGE
- accounts-xxx-xx 1/1 Running 0 2m
- accounts-br-xxx-xx 1/1 Running 0 2m
- creditcards-xxx-xx 1/1 Running 0 2m
- customer-xxx-xx 1/1 Running 0 2m
- discovery-xxx-xx 1/1 Running 0 2m
- mysqldb-xxx-xx 1/1 Running 0 2m
- payments-xxx-xx 1/1 Running 0 2m
- products-xxx-xx 1/1 Running 0 2m
- reviews-xxx-xx 1/1 Running 0 2m
- servicechannel-xxx-xx 1/1 Running 0 2m
- ```
diff --git a/content/en/docs/deployment/installation/jwe.md b/content/en/docs/deployment/installation/jwe.md
deleted file mode 100644
index 4cea7112..00000000
--- a/content/en/docs/deployment/installation/jwe.md
+++ /dev/null
@@ -1,64 +0,0 @@
----
-title: "JWE Generator Installation"
-linkTitle: "JWE Generator"
-weight: 30
----
-Install the JWE Generator utility for the Amplify Open Banking solution.
-
-{{% alert title="Note" color="primary" %}} This component is only required for Open Finance Brazil deployments.{{% /alert %}}
-
-## Download the JWE key generator tool Helm chart
-
-Download the Amplify Open Banking JWE key generator tool Helm chart to customize it locally.
-
-```bash
-helm pull axway/jwe-generator --untar
-```
-
-You should get an `jwe-generator` local folder.
-
-## Customize the JWE key generator tool Helm chart
-
-Customize the `jwe-generator/values.yaml` file as follows.
-
-| Value | Description | Default value |
-|:------------- |:------------------------------------- |:-------------- |
-| ingress.domainName | Set the domainname for all ingress. | \ |
-| global.dockerRegistry.username | Login name to pull Docker images from the Axway Repository. | None |
-| global.dockerRegistry.token | Password token to pull Docker images from the Axway Repository. | None |
-
-## Install the JWE key generator tool Helm chart
-
-1. Create the target namespace on the cluster:
-
- ```bash
- kubectl create namespace jwe-generator
- ```
-
-2. Install the JWE key generator Helm charts:
-
- ```bash
- helm install jwe jwe-generator -n jwe-generator
- ```
-
-3. Check that the status of the Helm command is deployed:
-
- ```
- NAME: jwe
- LAST DEPLOYED:
- NAMESPACE: jwe-generator
- STATUS: deployed
- REVISION: 1
- TEST SUITE: None
- ```
-
-## Verify the JWE key generator tool Helm chart deployment
-
-Wait a few minutes and use the following commands to check the deployment status.
-
- ```
- kubectl get pods -n jwe-generator
- NAME READY STATUS RESTARTS AGE
- jwe-jwe-generator-xxx-xx 1/1 Running 0 57s
-
- ```
diff --git a/content/en/docs/deployment/prerequisites.md b/content/en/docs/deployment/prerequisites.md
deleted file mode 100644
index ef0a1697..00000000
--- a/content/en/docs/deployment/prerequisites.md
+++ /dev/null
@@ -1,131 +0,0 @@
----
-title: "Prerequisites"
-linkTitle: "Prerequisites"
-weight: 1
----
-
-Amplify Open Banking deployment design is built on Kubernetes, which can be deployed either on premises or in the cloud.
-
-Preparing a Kubernetes cluster with the appropriate services and settings is required prior to the solution installation.
-
-## General prerequisites
-
-Prior to installation you need to perform the following tasks:
-
-* Read and understand the Architecture Overview guide.
-* Make choices that are described in the Architecture Overview guide including:
- * Choose a Kubernetes provider (cloud, on-premise, and so on).
- * Components that will be supported (consent applications, mock backend services, and so on).
- * Approach to database deployment (inside Kubernetes versus externalized services).
- * Components that reflect deployment model choice (certificate manager, load balancer/Ingress Controller, and so on).
-* Install the following command line tools:
- * Helm
- * Kubectl
-* Create a [service account](https://docs.axway.com/bundle/platform-management/page/docs/management_guide/organizations/managing_organizations/managing_service_accounts/index.html) in your organization in Amplify Platform to pull Helm charts and Docker images from the [Axway Repository](https://repository.axway.com/).
-* Deploy the external Cassandra database infrastructure.
-* Create a Kubernetes cluster that conforms to the architecture described in the Architecture Overview guide and reflects the architecture choices described above.
-
-These tasks must be completed for a successful installation.
-
-## Database requirements
-
-The solutions use the following external database components:
-
-* Cassandra for API Manager catalog. For Cassandra cluster requirements and installation, refer to [Cassandra installation](https://docs.axway.com/bundle/axway-open-docs/page/docs/apim_installation/apigtw_install/install_cassandra/index.html).
-
-## Kubernetes setup requirements
-
-A Kubernetes 1.23+ cluster is required to deploy the Amplify Open Banking Solution.
-
-### Resources
-
-Axway also recommends using Node Groups. Node Groups allow operators to group resources by node type based on characteristics such as machine resources, capabilities, or the virtual machine type. Taking this approach can reduce costs, increase performance, and allow specific type of machines to be managed discretely.
-
-The Kubernetes configuration must include three Node Groups:
-
-* *Application*: Hosts all Amplify Open Banking components:
- * Some components will have a Horizontal Pod Autoscaler to support the peak load (Axway recommends configuring a node autoscaler).
- * Most components, particularly API Gateway, require low latency.
- * The typical components for the production environment are:
-
-| Application | Component | Replicas |
-|:------------- |:------------------------------------- |:--------- |
-| API Management | API Gateway Manager | 1 |
-| API Management | APIManager | 1 |
-| API Management | APIGateway Traffic | 3-6 |
-| Amplify Agents | Discovery Agent | 1 |
-| Amplify Agents | Traceability Agent | 1 |
-| Identity | Cloudentity | 1-3 |
-| Identity | CockroachDB | 1-3 |
-| Identity | Redis | 1-3 |
-| Identity | TimescaleDB | 1-3 |
-
-{{% alert title="Note" color="primary" %}} The consent and backend components are not considered here, because they usually are replaced by customer's custom components.{{% /alert %}}
-
-* *Transversal*: Hosts non-application components such as monitoring tools and infrastructure components such as the Certificate Manager and external DNS. This group can be configured without a node autoscaler.
-* *Database*: Hosts all stateful applications.
-
-An affinity node is used on each component to deploy them on the appropriate nodes.
-
-The typical infrastructure requirement for Kubernetes cluster are:
-
-* Non-Production environment:
- * 24 vCPus.
- * 48 GB of memory.
- * 150 GB of disk.
-* Production environment:
- * 38 vCPUs.
- * 76 GB of memory.
- * 500 GB of disk.
-
-{{% alert title="Note" color="primary" %}} The configuration of master nodes is out-of-scope on this page.{{% /alert %}}
-
-### Subnets
-
-A complete architecture requires a minimum of 3 subnets:
-
-* *Bastion*: Required for operators to connect from a Bastion host (although this can be substituted for an alternative solution). Access to pods on all required ports must be allowed. A subnet mask of /32 is considered sufficient.
-* *Kubernetes*: The design of this subnet can vary based on a number of conditions:
- * This subnet must have access to both the customer backend services and the database subnet.
- * If CNI is activated, enough IP addresses must be allocated for nodes and the maximum number of pods in the platform. Amplify Open Banking generates between 100 and 120 objects that consume an IP address.
- * A subnet mask /24 is therefore recommended to support scaling, upgrade, and others tools for production.
-* *Database*: For databases provided inside the Kubernetes cluster a subnet mask of /29 is recommended.
-
-Each subnet must be protected by a firewall implemented at Layer 4 of the OSI model with open routes kept to a bare minimum.
-
-### Kubernetes components
-
-The following components are highly recommended.
-
-#### Ingress controller
-
-To control all external traffic, an Ingress controller is required. It is recommended to use the [Nginx Ingress](https://github.com/kubernetes/ingress-nginx/tree/main/charts/ingress-nginx) controller to use as a reverse proxy and manage the MTLS and TLS termination, and load-balancing when required.
-
-Select the appropriate version that is compatible with your cluster with a minimum of 0.35. The ingress annotations of our Helm chart have been written for the 0.35 version. A more recent version of the `nginx-ingress` may impact these annotations. Review the nginx official documentation to update them accordingly.
-
-You can use NGINX or another ingress controller with the following requirements:
-
-* Encode certificate in header X-SSL-CERT in web format.
-* Return http error 400 if client uses a bad certificate.
-* Manage multiple root CAs according to different client certificates.
-* Limit cypher spec usage to “DHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384".
-* Use request header size compatible with 8K.
-* Deny public access to Cloudentity path `/app/default/admin`.
-
-#### Certificate Manager
-
-We recommend that you use [Cert-Manager](https://github.com/jetstack/cert-manager/tree/master/deploy/charts/cert-manager) to easily manage certificates that are used in the Amplify Open Banking Solution.
-
-If you have specific certificates you want to use during installation, you can avoid using *cert-manager* but more configuration is required during deployment.
-
-#### DNS
-
-It is also highly recommended to use [External-DNS](https://github.com/bitnami/charts/tree/master/bitnami/external-dns) to synchronize ingress hosts in a DNS zone.
-
-In case `external-dns` is not available in the cluster, you must manually configure the ingress host in your DNS zone. Also remove the cert-manager annotation in all ingress hosts.
-
-
diff --git a/content/en/docs/deployment/upgrade.md b/content/en/docs/deployment/upgrade.md
deleted file mode 100644
index 64a1c31e..00000000
--- a/content/en/docs/deployment/upgrade.md
+++ /dev/null
@@ -1,79 +0,0 @@
----
-title: "Upgrade"
-linkTitle: "Upgrade"
-weight: 4
----
-
-The use of Helm charts and Docker images greatly improves and simplifies the Amplify Open Banking upgrade process. With each new release, a new version of the Helm chart will also be released. This new version will have the latest images at the time of the release set as the default, along with any additional features or configuration that might have been added to the chart. If other images are released in between Helm chart releases, such as for patch or security fixes, it is up to the user to update their Helm configuration to pull these new images. The chart is not backward compatible, and you cannot use a new version of the chart and continue using older versions of the images.
-
-## Upgrade Steps
-
-Backup your previous deployments if reusing the same directory:
-
-```bash
-mkdir previous-version
-
-mv open-banking-apim previous-version/
-mv open-banking-cloudentity previous-version/
-mv open-banking-consent-apps previous-version/
-
-# for FDX
-mv open-banking-fdx-apim-config previous-version/
-mv open-banking-fdx-backend previous-version/
-
-# for Open Finance Brazil
-mv open-banking-apim-config previous-version/
-mv open-banking-backend-chart previous-version/
-mv open-banking-jwe-generator previous-version/
-```
-
-Update your repo:
-
-```bash
-helm repo update
-```
-
-Pull only the Helm charts you want to upgrade:
-
-```bash
-helm search repo axway
-
-helm pull axway/open-banking-apim --untar
-helm pull axway/open-banking-cloudentity --untar
-helm pull axway/open-banking-consent-apps --untar
-
-# FDX components only
-helm pull axway/open-banking-fdx-apim-config --untar
-helm pull axway/open-banking-fdx-backend --untar
-
-# Open Finance Brazil components only
-helm pull axway/open-banking-apim-config --untar
-helm pull axway/open-banking-backend-chart --untar
-helm pull axway/open-banking-jwe-generator --untar
-```
-
-For each new Helm chart, update `open-banking-xxxxx/values.yaml` using the:
-
-* Install documentation of the components.
-* Previous values used in `previous-version/open-banking-xxxxx/value.yaml`.
-* Release Notes.
-
-Execute the upgrade commands as required:
-
-```bash
-helm upgrade apim -n open-banking-apim open-banking-apim
-helm upgrade acp -n open-banking-cloudentity open-banking-cloudentity
-helm upgrade consent-apps -n open-banking-consent-apps open-banking-consent-apps
-
-# FDX components only
-helm upgrade apim-config -n open-banking-apim open-banking-apim-config
-helm upgrade backend-services -n open-banking-backend open-banking-fdx-backend
-
-# Open Finance components only
-helm upgrade apim-config -n open-banking-apim open-banking-apim-config
-helm upgrade backend-services -n open-banking-backend open-banking-backend-chart
-```
diff --git a/package-lock.json b/package-lock.json
index 7980a401..113393e7 100644
--- a/package-lock.json
+++ b/package-lock.json
@@ -211,12 +211,12 @@
}
},
"node_modules/braces": {
- "version": "3.0.2",
- "resolved": "https://registry.npmjs.org/braces/-/braces-3.0.2.tgz",
- "integrity": "sha512-b8um+L1RzM3WDSzvhm6gIz1yfTbBt6YTlcEKAvsmqCZZFw46z626lVj9j1yEPW33H5H+lBQpZMP1k8l+78Ha0A==",
+ "version": "3.0.3",
+ "resolved": "https://registry.npmjs.org/braces/-/braces-3.0.3.tgz",
+ "integrity": "sha512-yQbXgO/OSZVD2IsiLlro+7Hf6Q18EJrKSEsdoMzKePKXct3gvD8oLcOQdIzGupr5Fj+EDe8gO/lxc1BzfMpxvA==",
"dev": true,
"dependencies": {
- "fill-range": "^7.0.1"
+ "fill-range": "^7.1.1"
},
"engines": {
"node": ">=8"
@@ -505,9 +505,9 @@
}
},
"node_modules/fill-range": {
- "version": "7.0.1",
- "resolved": "https://registry.npmjs.org/fill-range/-/fill-range-7.0.1.tgz",
- "integrity": "sha512-qOo9F+dMUmC2Lcb4BbVvnKJxTPjCm+RRpe4gDuGrzkL7mEVl/djYSu2OdQ2Pa302N4oqkSg9ir6jaLWJ2USVpQ==",
+ "version": "7.1.1",
+ "resolved": "https://registry.npmjs.org/fill-range/-/fill-range-7.1.1.tgz",
+ "integrity": "sha512-YsGpe3WHLK8ZYi4tWDg2Jy3ebRz2rXowDxnld4bkQB00cc/1Zw9AWnC0i9ztDJitivtQvaI9KaLyKrc+hBW0yg==",
"dev": true,
"dependencies": {
"to-regex-range": "^5.0.1"
@@ -1279,12 +1279,12 @@
}
},
"node_modules/micromatch": {
- "version": "4.0.5",
- "resolved": "https://registry.npmjs.org/micromatch/-/micromatch-4.0.5.tgz",
- "integrity": "sha512-DMy+ERcEW2q8Z2Po+WNXuw3c5YaUSFjAO5GsJqfEl7UjvtIuFKO6ZrKvcItdy98dwFI2N1tg3zNIdKaQT+aNdA==",
+ "version": "4.0.8",
+ "resolved": "https://registry.npmjs.org/micromatch/-/micromatch-4.0.8.tgz",
+ "integrity": "sha512-PXwfBhYu0hBCPw8Dn0E+WDYb7af3dSLVWKi3HGv84IdF4TyFoC0ysxFd0Goxw7nSv4T/PzEJQxsYsEiFCKo2BA==",
"dev": true,
"dependencies": {
- "braces": "^3.0.2",
+ "braces": "^3.0.3",
"picomatch": "^2.3.1"
},
"engines": {
@@ -1313,9 +1313,9 @@
}
},
"node_modules/nanoid": {
- "version": "3.3.6",
- "resolved": "https://registry.npmjs.org/nanoid/-/nanoid-3.3.6.tgz",
- "integrity": "sha512-BGcqMMJuToF7i1rt+2PWSNVnWIkGCU78jBG3RxO/bZlnZPK2Cmi2QaffxGO/2RvWi9sL+FAiRiXMgsyxQ1DIDA==",
+ "version": "3.3.7",
+ "resolved": "https://registry.npmjs.org/nanoid/-/nanoid-3.3.7.tgz",
+ "integrity": "sha512-eSRppjcPIatRIMC1U6UngP8XFcz8MQWGQdt1MTBQ7NaAmvXDfvNxbvWV3x2y6CdEUciCSsDHDQZbhYaB8QEo2g==",
"dev": true,
"funding": [
{
@@ -1513,9 +1513,9 @@
}
},
"node_modules/picocolors": {
- "version": "1.0.0",
- "resolved": "https://registry.npmjs.org/picocolors/-/picocolors-1.0.0.tgz",
- "integrity": "sha512-1fygroTLlHu66zi26VoTDv8yRgm0Fccecssto+MhsZ0D/DGW2sm8E8AjW7NU5VVTRt5GxbeZ5qBuJr+HyLYkjQ==",
+ "version": "1.1.0",
+ "resolved": "https://registry.npmjs.org/picocolors/-/picocolors-1.1.0.tgz",
+ "integrity": "sha512-TQ92mBOW0l3LeMeyLV6mzy/kWr8lkd/hp3mTg7wYK7zJhuBStmGMBG0BdeDZS/dZx1IukaX6Bk11zcln25o1Aw==",
"dev": true
},
"node_modules/picomatch": {
@@ -1540,9 +1540,9 @@
}
},
"node_modules/postcss": {
- "version": "8.4.24",
- "resolved": "https://registry.npmjs.org/postcss/-/postcss-8.4.24.tgz",
- "integrity": "sha512-M0RzbcI0sO/XJNucsGjvWU9ERWxb/ytp1w6dKtxTKgixdtQDq4rmx/g8W1hnaheq9jgwL/oyEdH5Bc4WwJKMqg==",
+ "version": "8.4.45",
+ "resolved": "https://registry.npmjs.org/postcss/-/postcss-8.4.45.tgz",
+ "integrity": "sha512-7KTLTdzdZZYscUc65XmjFiB73vBhBfbPztCYdUNvlaso9PrzjzcmjqBPR0lNGkcVlcO4BjiO5rK/qNz+XAen1Q==",
"dev": true,
"funding": [
{
@@ -1559,9 +1559,9 @@
}
],
"dependencies": {
- "nanoid": "^3.3.6",
- "picocolors": "^1.0.0",
- "source-map-js": "^1.0.2"
+ "nanoid": "^3.3.7",
+ "picocolors": "^1.0.1",
+ "source-map-js": "^1.2.0"
},
"engines": {
"node": "^10 || ^12 || >=14"
@@ -1801,9 +1801,9 @@
}
},
"node_modules/source-map-js": {
- "version": "1.0.2",
- "resolved": "https://registry.npmjs.org/source-map-js/-/source-map-js-1.0.2.tgz",
- "integrity": "sha512-R0XvVJ9WusLiqTCEiGCmICCMplcCkIwwR11mOSD9CR5u+IXYdiseeEuXCVAjS54zqwkLcPNnmU4OeJ6tUrWhDw==",
+ "version": "1.2.1",
+ "resolved": "https://registry.npmjs.org/source-map-js/-/source-map-js-1.2.1.tgz",
+ "integrity": "sha512-UXWMKhLOwVKb728IUtQPXxfYU+usdybtUrK/8uGE8CQMvrhOpwvzDBwj0QhSL7MQc7vIsISBG8VQ8+IDQxpfQA==",
"dev": true,
"engines": {
"node": ">=0.10.0"
diff --git a/src/plant-uml/ciba-example.puml b/src/plant-uml/ciba-example.puml
index afe88c97..0684bc00 100644
--- a/src/plant-uml/ciba-example.puml
+++ b/src/plant-uml/ciba-example.puml
@@ -5,18 +5,14 @@ hide footbox
participant "Data\nRecipient\nApp" as DR
-box Infrastructure #6FA8DC
-participant "Ingress\nController" as INGRESS
+box Amplify Integration #6FA8DC
participant "API\nGateway" as API_GATEWAY
-end box
-
-box Identity and Access Control #94c47d
-participant "Identity Management\n---\nAuthorisation Server" as IAM
participant "Consent\nManagement" as CONSENT
+participant "Core Banking \nConnector" as CBC
end box
-box Open Banking APIs #fc877e
-participant "Bacend\nIntegration\nApplication" as BIA
+box Identity and Access Control #94c47d
+participant "Identity Management\n---\nAuthorization Server" as IAM
end box
box Core Banking Applications #d5a6bd
@@ -57,10 +53,10 @@ modes. The supported modes must be made pushed in the AS OpenID
Configuration.
end note
-DR -> INGRESS: ""POST /connect/register""
+DR -> API_GATEWAY: ""POST /connect/register""
-note right of INGRESS
-The Kubernetes Ingress Controller is responsible for TLS
+note right of API_GATEWAY
+The API Gateway is responsible for TLS
termination and perfoming an OCSP call to the Certificate
Authority to ensure the client certificate presented is
valid. The fingerprint of the certificate will be forwarded
@@ -68,8 +64,8 @@ to Identity Management to verify the validity of the OAuth
Client as this cannot be asserted via OCSP.
end note
-INGRESS -> OCSP: Check Client Certificate Validity
-INGRESS <-- OCSP: Response
+API_GATEWAY -> OCSP: Check Client Certificate Validity
+API_GATEWAY <-- OCSP: Response
'INGRESS -> API_GATEWAY: Registration Request
/'
@@ -87,11 +83,11 @@ INGRESS <-- API_GATEWAY: Response
DR <-- INGRESS: Response
'/
-INGRESS -> IAM: Registration Request
+API_GATEWAY -> IAM: Registration Request
IAM -> IAM: Verify Client
IAM -> IAM: Store Client Parameters
-INGRESS <-- IAM: Response
-DR <-- INGRESS: Response
+API_GATEWAY <-- IAM: Response
+DR <-- API_GATEWAY: Response
== Part 1: Create Consent and Send Authentication Request ==
@@ -102,15 +98,15 @@ is through Mutual Authentication over TLS but it could
equally be using ""private_key_jwt"".
end note
-DR -> INGRESS: ""POST /oauth2/token""
-INGRESS -> OCSP: Check Client Certificate Validity
-INGRESS <-- OCSP: Response
-INGRESS -> IAM: ""POST /oauth2/token""
+DR -> API_GATEWAY: ""POST /oauth2/token""
+API_GATEWAY -> OCSP: Check Client Certificate Validity
+API_GATEWAY <-- OCSP: Response
+API_GATEWAY -> IAM: ""POST /oauth2/token""
'API_GATEWAY -> IAM: ""POST /oauth2/token""
IAM -> IAM: Verify Client
'API_GATEWAY <- IAM: ""200 OK""\n""{"access_token": "..."}""
-INGRESS <-- IAM: ""200 OK""\n""{"access_token": "..."}""
-DR <-- INGRESS: ""200 OK""\n""{"access_token": "..."}""
+API_GATEWAY <-- IAM: ""200 OK""\n""{"access_token": "..."}""
+DR <-- API_GATEWAY: ""200 OK""\n""{"access_token": "..."}""
note right of DR
With the Access Token in hand the Data Recipient can then
@@ -119,15 +115,14 @@ before the Authentication Request as the value of the
""consentId"" is required to set the value of the scope.
end note
-DR -> INGRESS: ""POST /payments/v1/consents""
-INGRESS -> OCSP: Check Client Certificate Validity
-INGRESS <-- OCSP: Response
-INGRESS -> API_GATEWAY: ""POST /payments/v1/consents""
+DR -> API_GATEWAY: ""POST /payments/v1/consents""
+API_GATEWAY -> OCSP: Check Client Certificate Validity
+API_GATEWAY <-- OCSP: Response
+API_GATEWAY -> API_GATEWAY: ""POST /payments/v1/consents""
API_GATEWAY -> CONSENT: ""POST /payments/v1/consents""
CONSENT -> CONSENT: Validate consent request properties
-API_GATEWAY <-- CONSENT: ""201 Created""\n""{consentId: "..."}""
-INGRESS <-- API_GATEWAY: ""201 Created""\n""{consentId: "..."}""
-DR <-- INGRESS: ""201 Created""\n""{consentId: "..."}""
+API_GATEWAY <-- CONSENT: ""201 Created""\n""{consentId: "..."}""API_GATEWAY
+DR <-- API_GATEWAY: ""201 Created""\n""{consentId: "..."}""
note right of DR
The Data Recipient App can now create and send the Authentication
@@ -136,9 +131,9 @@ of the ""consentId"" returned by Identity Management.
end note
DR -> DR: Create Authentication Request
-DR -> INGRESS: ""POST /bc-authorize""
-INGRESS -> OCSP: Check Client Certificate Validity
-INGRESS <-- OCSP: Response
+DR -> API_GATEWAY: ""POST /bc-authorize""
+API_GATEWAY -> OCSP: Check Client Certificate Validity
+API_GATEWAY <-- OCSP: Response
/'
INGRESS -> API_GATEWAY: ""POST /bc-authorize""
@@ -158,7 +153,7 @@ API_GATEWAY -> IAM: Forward Authentication Request
IAM -> IAM: Validate Authentication Request
'/
-INGRESS -> IAM: ""POST /bc-authorize""
+API_GATEWAY -> IAM: ""POST /bc-authorize""
note right of IAM
As with the redirection-based FAPI profiles the Authentication
@@ -181,8 +176,8 @@ case-by-case basis.
end note
IAM -> ASPSP_IDP: Send Authentication Request notification
-INGRESS <-- IAM: ""201 Created""\n""{auth_req_id: "..."}""
-DR <-- INGRESS: ""201 Created""\n""{auth_req_id: "..."}""
+API_GATEWAY <-- IAM: ""201 Created""\n""{auth_req_id: "..."}""
+DR <-- API_GATEWAY: ""201 Created""\n""{auth_req_id: "..."}""
== Part 2: Customer Authenticates at Mobile Banking App ==
@@ -239,13 +234,11 @@ In this example the Customer is the sole account
holder and therefore no further authorizations are required.
end note
-MOBILE -> INGRESS: Retrieve consent
-INGRESS -> API_GATEWAY: Retrieve consent
+MOBILE -> API_GATEWAY: Retrieve consent
API_GATEWAY -> CONSENT: Retrieve consent
CONSENT -> CONSENT: Retrieve Consent
API_GATEWAY <-- CONSENT: Response
-INGRESS <-- API_GATEWAY: Response
-MOBILE <-- INGRESS: Response
+MOBILE <-- API_GATEWAY: Response
note right of ASPSP_API
The Consent Confirmation screen requires the following properties to be displayed:
@@ -300,13 +293,11 @@ MOBILE -> MOBILE: Render consent\nconfirmation screen
MOBILE -> PSU: Request consent\nconfirmation
MOBILE <-- PSU: Confirm consent
-MOBILE -> INGRESS: Update consent as authorized
-INGRESS -> API_GATEWAY: Update consent as authorized
+MOBILE -> API_GATEWAY: Update consent as authorized
API_GATEWAY -> CONSENT: Update consent
CONSENT -> CONSENT: Update Consent
API_GATEWAY <-- CONSENT: Response
-INGRESS <-- API_GATEWAY: Response
-MOBILE <-- INGRESS: Response
+MOBILE <-- API_GATEWAY: Response
note left of MOBILE
The final step is to call the Identity Management
@@ -351,29 +342,29 @@ tokens (Access, Refresh, ID) from the Token endpoint.
end note
loop Exit when Authentication Request successful
-DR -> INGRESS: ""POST /token auth_req_id=...""
-INGRESS -> OCSP: Check Client Certificate Validity
-INGRESS <-- OCSP: Response
-INGRESS -> IAM: ""POST /token auth_req_id=...""
+DR -> API_GATEWAY: ""POST /token auth_req_id=...""
+API_GATEWAY -> OCSP: Check Client Certificate Validity
+API_GATEWAY <-- OCSP: Response
+API_GATEWAY -> IAM: ""POST /token auth_req_id=...""
'API_GATEWAY -> IAM: ""POST /token auth_req_id=...""
IAM -> IAM: Retrieve Authentication request
IAM -> IAM: Check status
'API_GATEWAY <-- IAM: ""400 Bad Request {...}""
-INGRESS <-- IAM: ""400 Bad Request {...}""
-DR <-- INGRESS: ""400 Bad Request {...}""
+API_GATEWAY <-- IAM: ""400 Bad Request {...}""
+DR <-- API_GATEWAY: ""400 Bad Request {...}""
end loop
-DR -> INGRESS: ""POST /token auth_req_id=...""
-INGRESS -> OCSP: Check Client Certificate Validity
-INGRESS <-- OCSP: Response
+DR -> API_GATEWAY: ""POST /token auth_req_id=...""
+API_GATEWAY -> OCSP: Check Client Certificate Validity
+API_GATEWAY <-- OCSP: Response
'INGRESS -> API_GATEWAY: ""POST /token auth_req_id=...""
-INGRESS -> IAM: ""POST /token auth_req_id=...""
+API_GATEWAY -> IAM: ""POST /token auth_req_id=...""
IAM -> IAM: Retrieve Authentication request
IAM -> IAM: Check status
IAM -> IAM: Create tokens
'API_GATEWAY <-- IAM: ""200 OK {...}""
-INGRESS <-- IAM: ""200 OK {...}""
-DR <-- INGRESS: ""200 OK {...}""
+API_GATEWAY <-- IAM: ""200 OK {...}""
+DR <-- API_GATEWAY: ""200 OK {...}""
else Client Registered Ping Mode
@@ -387,16 +378,16 @@ end note
DR <- IAM: Authentication Request complete notification
DR --> IAM: ""204 No Content""
-DR -> INGRESS: ""POST /token auth_req_id=...""
-INGRESS -> OCSP: Check Client Certificate Validity
-INGRESS <-- OCSP: Response
+DR -> API_GATEWAY: ""POST /token auth_req_id=...""
+API_GATEWAY -> OCSP: Check Client Certificate Validity
+API_GATEWAY <-- OCSP: Response
'INGRESS -> API_GATEWAY: ""POST /token auth_req_id=...""
-INGRESS -> IAM: ""POST /token auth_req_id=...""
+API_GATEWAY -> IAM: ""POST /token auth_req_id=...""
IAM -> IAM: Retrieve Authentication request
IAM -> IAM: Create tokens
'API_GATEWAY <-- IAM: ""200 OK {...}""
-INGRESS <-- IAM: ""200 OK {...}""
-DR <-- INGRESS: ""200 OK {...}""
+API_GATEWAY <-- IAM: ""200 OK {...}""
+DR <-- API_GATEWAY: ""200 OK {...}""
else Client Registered Push Mode
@@ -425,10 +416,9 @@ is bound to this single operation and will be revoked once
the payment instruction is successfully transmitted.
end note
-DR -> INGRESS: ""POST /payments/v1/pix/payments""
-INGRESS -> OCSP: Check Client Certificate Validity
-INGRESS <-- OCSP: Response
-INGRESS -> API_GATEWAY: ""POST /payments/v1/pix/payments""
+DR -> API_GATEWAY: ""POST /payments/v1/pix/payments""
+API_GATEWAY -> OCSP: Check Client Certificate Validity
+API_GATEWAY <-- OCSP: Response
note right of API_GATEWAY
The approach to Access Token introspection remains the same under payments
@@ -444,25 +434,24 @@ API_GATEWAY -> API_GATEWAY: Introspect Access Token properties
note right of API_GATEWAY
On introspecting the Access Token the API Gateway will decorate the
request with the debtor account which is stored with the Consent. This can
-then be forwarded to the Backend Integration Application and used to make the correct
+then be forwarded to the Core Banking Connector and used to make the correct
payment instruction in the Banking Systems.
end note
API_GATEWAY -> API_GATEWAY: Decorate request with debtor account
-API_GATEWAY -> BIA: ""POST /payments/v1/pix/payments""
+API_GATEWAY -> CBC: ""POST /payments/v1/pix/payments""
-note right of BIA
+note right of CBC
This flow is non-normative and will vary on customer requirements.
It //could// be to a PIX-compliant API or any other available mechanism
to make a PIX payment.
end note
-BIA -> BIA: Mediate request payload
-BIA -> ASPSP_API: Deliver payment instruction to Banking System API
-BIA <-- ASPSP_API: Response
-BIA -> BIA: Mediate response payload
-API_GATEWAY <-- BIA: ""201 Created""\n""{paymentId: "..."}""
-INGRESS <-- API_GATEWAY: ""201 Created""\n""{paymentId: "..."}""
-DR <-- INGRESS: ""201 Created""\n""{paymentId: "..."}""
+CBC -> CBC: Mediate request payload
+CBC -> ASPSP_API: Deliver payment instruction to Banking System API
+CBC <-- ASPSP_API: Response
+CBC -> CBC: Mediate response payload
+API_GATEWAY <-- CBC: ""201 Created""\n""{paymentId: "..."}""
+DR <-- API_GATEWAY: ""201 Created""\n""{paymentId: "..."}""
@enduml
\ No newline at end of file
diff --git a/src/plant-uml/fdx-end-to-end-web-journey.puml b/src/plant-uml/fdx-end-to-end-web-journey.puml
index 2e8ceb74..b278bb6a 100644
--- a/src/plant-uml/fdx-end-to-end-web-journey.puml
+++ b/src/plant-uml/fdx-end-to-end-web-journey.puml
@@ -5,18 +5,15 @@ title \n\n\n
actor "End User" as PSU
participant "Data\nRecipient" as DR
-box Infrastructure #6FA8DC
-participant "Ingress\nController" as INGRESS
+box Amplify Integration #6FA8DC
participant "API\nGateway" as API_GATEWAY
-end box
-
-box Identity and Access Control #94c47d
-participant "Identity Management\n---\nAuthorisation Server" as IAM
participant "Consent\nManagement" as CONSENT
+participant "Core Banking \nConnector" as CBC
end box
-box Open Banking APIs #fc877e
-participant "Backend\nIntegration\nApplication" as BIA
+box Identity and Access Control #94c47d
+participant "Identity Management\n---\nAuthorization Server" as IAM
+participant "Consent Grant\nApp" as CONSENT_WEB
end box
box Core Banking Applications #d5a6bd
@@ -24,15 +21,6 @@ participant "Banking\nIdentity\nProvider" as ASPSP_WEB
participant "Banking\nSystems" as ASPSP_API
end box
-/'
-box Open Banking Directory
-participant "Participants\nList" as OBD_PARTICIPANTS
-participant "JSON Web\nKey Set" as OBD_JWKS
-end box
-
-participant "Certificate\nAuthority\n---\nOCSP Endpoint" as OCSP
-'/
-
hide footbox
'skinparam defaultFontName Roboto
skinparam BoxPadding 20
@@ -40,7 +28,7 @@ skinparam BoxPadding 20
note right of PSU
Overview
===
-This diagram shows the end-to-end web journey for obtaining Consent and starting to collect
+This diagram sh ows the end-to-end web journey for obtaining Consent and starting to collect
Account Information data. The goal is to place the components from the Architecture Overview
in context.
end note
@@ -66,7 +54,7 @@ PSU -> DR: Confirm bank selection
note right of DR
With the consent of the End User obtained the DR can now call the
Authorization Server API at the correct bank. Note at this point
-Consent is usual termed "Intent" as it hasyet to confirmed at the bank.
+Consent is usual termed "Intent" as it has yet to be confirmed at the bank.
end note
DR -> DR: Create Intent payload
@@ -81,15 +69,14 @@ The par request MUST contain an authorization details parameter
{
"type": "fdx_v1.0",
"consentRequest": {
- "durationType": "ONETIME",
+ "durationType": "ONE_TIME",
"lookbackPeriod": 60,
"resources": [
{
"resourceType": "ACCOUNT",
"dataClusters": [
"ACCOUNT_DETAILED",
- "TRANSACTIONS",
- "STATEMENTS"
+ "TRANSACTIONS"
]
}
]
@@ -99,8 +86,13 @@ The par request MUST contain an authorization details parameter
}
end note
-DR -> IAM: ""POST /par "{"authorization_details":[{"type":"fdx_v1.0","consentRequest":"...."}]"""
-DR <-- IAM: return request_uri
+DR -> API_GATEWAY: ""POST /par "{"authorization_details":[{"type":"fdx_v1.0","consentRequest":"...."}]"""
+API_GATEWAY -> API_GATEWAY: Validate certificate
+API_GATEWAY -> IAM: ""POST /par "{"authorization_details":[{"type":"fdx_v1.0","consentRequest":"...."}]"""
+API_GATEWAY <-- IAM: return request_uri
+API_GATEWAY --> CONSENT: Create consent
+API_GATEWAY <-- CONSENT: Consent created
+DR <-- API_GATEWAY: return request_uri
== Part 3: User authentication, consent and authorization ==
@@ -112,10 +104,12 @@ DR -> IAM: ""GET /authorize&request_uri=""
IAM -> ASPSP_WEB: ""REDIRECT /login""
ASPSP_WEB -> PSU: ""USER login""
PSU --> ASPSP_WEB: ""200 OK {...}""
-ASPSP_WEB --> CONSENT: Serve Consent and Account Confirmation Screen
-CONSENT --> PSU: Serve Consent and Account Confirmation Screen
-PSU --> CONSENT: "Consent confirmation is correct
-CONSENT --> IAM: ""201 CREATED {"consentId":"..."}""
+ASPSP_WEB --> CONSENT_WEB: Serve Consent and\nAccount Confirmation Screen
+CONSENT_WEB --> PSU: Serve Consent and Account Confirmation Screen
+PSU --> CONSENT_WEB: "Consent confirmation is correct
+CONSENT_WEB --> CONSENT: Update consent resources and status
+CONSENT --> CONSENT_WEB: Consent updated
+CONSENT --> IAM: Redirect with success
IAM --> DR: ""200 OK {"code":"..."}""
note right of DR
@@ -136,15 +130,13 @@ end note
DR -> API_GATEWAY: ""GET /fdx/{version}/core/accounts""
note right of API_GATEWAY
-Introspect Access Token
+Validate Access Token
end note
-API_GATEWAY -> IAM: ""POST /token-introspection""
-IAM --> API_GATEWAY: ""200 OK""\n""{"status": "..."}""
-API_GATEWAY --> API_GATEWAY: Verify Access Token scope
-API_GATEWAY -> BIA: ""GET /fdx/{version}/core/accounts""
-BIA -> ASPSP_API: ""GET /fdx/{version}/core/accounts""
-ASPSP_API -> BIA: ""200 OK""\n""{"accounts": "..."}""
-BIA -> API_GATEWAY: ""200 OK""\n""{"accounts": "..."}""
+API_GATEWAY --> API_GATEWAY: Verify Access Token claims
+API_GATEWAY -> CBC: ""GET /fdx/{version}/core/accounts""
+CBC -> ASPSP_API: ""GET /fdx/{version}/core/accounts""
+ASPSP_API -> CBC: ""200 OK""\n""{"accounts": "..."}""
+CBC -> API_GATEWAY: ""200 OK""\n""{"accounts": "..."}""
API_GATEWAY -> DR: ""200 OK""\n""{"accounts": "..."}""
@enduml
\ No newline at end of file
diff --git a/src/plant-uml/mtls-termination-verification.puml b/src/plant-uml/mtls-termination-verification.puml
index 90ec7ef6..36287179 100644
--- a/src/plant-uml/mtls-termination-verification.puml
+++ b/src/plant-uml/mtls-termination-verification.puml
@@ -4,18 +4,13 @@ title \n\n
participant "Data\nRecipient" as DR
-box Infrastructure #6FA8DC
-participant "Ingress\nController" as INGRESS
+box Amplify Integration #6FA8DC
participant "API\nGateway" as API_GATEWAY
-end box
-
-box Open Banking APIs #fc877e
-'participant "API\nGateway" as API_GATEWAY
-participant "Backend\nIntegration\nApplication" as BIA
+participant "Core Banking\nConnector" as CBC
end box
box Identity and Access Control #94c47d
-participant "Identity\nManagement" as IAM
+participant "Authorization\nServer" as IAM
end box
participant "Market\nCertificate\nAuthority" as CA
@@ -34,9 +29,8 @@ This diagram shows the specifics of mutual authentication
as implemented in the open banking accelerator.
end note
-DR -> INGRESS: Request protected endpoint
-INGRESS -> INGRESS: Validate certificate chain
-INGRESS -> API_GATEWAY: Request protected endpoint
+DR -> API_GATEWAY: Request protected endpoint
+API_GATEWAY -> API_GATEWAY: Validate certificate chain
API_GATEWAY -> CA: Check certificate status (OCSP/CRL)
API_GATEWAY <-- CA: Response
@@ -48,22 +42,20 @@ certificate is enforced through FAPI which
references [[https://datatracker.ietf.org/doc/html/rfc8705 RFC 8705]].
|||
To support this the API Gateway uses the
-Access Token introspection endpoint to
-retrieve the stored certificate fingerprint.
+JWT claims to retrieve the stored
+certificate fingerprint.
end note
-API_GATEWAY -> IAM: Access Token\nintrospection
-IAM -> IAM: Retrieve Access\nToken properties
-API_GATEWAY <-- IAM: Response
+API_GATEWAY -> IAM: Call JWKS Endpoint to validate JWT access token
+API_GATEWAY <-- IAM: Return JWKS
+API_GATEWAY -> API_GATEWAY: Get claims from JWT
API_GATEWAY -> API_GATEWAY: Calculate certificate\nfingerprint
API_GATEWAY -> API_GATEWAY: Compare stored and\ncalculated fingerprints
end alt
-API_GATEWAY -> BIA: Request protected endpoint
-BIA -> ASPSP_API: Request backend data or service
-BIA <-- ASPSP_API: Response
-API_GATEWAY <-- BIA: Response
-INGRESS <-- API_GATEWAY: Response
-DR <-- INGRESS: Response
+API_GATEWAY -> CBC: Request protected endpoint
+CBC -> ASPSP_API: Request backend data or service
+CBC <-- ASPSP_API: Response
+API_GATEWAY <-- CBC: Response
@enduml
\ No newline at end of file
diff --git a/src/plant-uml/user-consent-filtering-arch-overview.puml b/src/plant-uml/user-consent-filtering-arch-overview.puml
index 80855143..ebc23fa4 100644
--- a/src/plant-uml/user-consent-filtering-arch-overview.puml
+++ b/src/plant-uml/user-consent-filtering-arch-overview.puml
@@ -4,9 +4,9 @@ title \n\n
participant "Data\nRecipient" as DR
-box Open Banking APIs #fc877e
+box Amplify Integration #fc877e
participant "API\nGateway" as API_GATEWAY
-participant "Backend\nIntegration\nApplication" as BIA
+participant "Core Banking\nConnector" as CBC
end box
box Identity and Access Control #94c47d
@@ -38,9 +38,9 @@ end note
DR -> API_GATEWAY: Request Account Information Resource\nwith valid Access Token
-API_GATEWAY -> IAM: Call Access Token Introspect Endpoint
-API_GATEWAY <-- IAM: Return introspection information
-API_GATEWAY -> API_GATEWAY: Inspect request
+API_GATEWAY -> IAM: Call JWKS Endpoint to validate JWT access token
+API_GATEWAY <-- IAM: Return JWKS
+API_GATEWAY -> API_GATEWAY: Validate token and get claims
alt DR does not have Consent for the requested account or resource
@@ -60,45 +60,23 @@ API_GATEWAY -> API_GATEWAY: Augment request\nwith consented accounts/permissions
alt Filtering is performed at Core Banking Application
-API_GATEWAY -> BIA: Forward request with\nconsented accounts/permissions
-BIA -> BIA: Create request for consented accounts
-BIA -> ASPSP_API: Request data for consented accounts
+API_GATEWAY -> CBC: Forward request with\nconsented accounts/permissions
+CBC -> CBC: Create request for consented accounts
+CBC -> ASPSP_API: Request data for consented accounts
ASPSP_API -> ASPSP_API: Retrieve data for consented accounts
ASPSP_API -> ASPSP_API: Apply permissions to requested data
-BIA <-- ASPSP_API: Return data for consented accounts
-API_GATEWAY <-- BIA: Return response
+CBC <-- ASPSP_API: Return data for consented accounts
+API_GATEWAY <-- CBC: Return response
-else Filtering is performed at Backend Integration Application
+else Filtering is performed at Core Banking Connector
-API_GATEWAY -> BIA: Forward request with\nconsented accounts/permissions
-BIA -> BIA: Create request for consented accounts
-BIA -> ASPSP_API: Request data for consented accounts
+API_GATEWAY -> CBC: Forward request with\nconsented accounts/permissions
+CBC -> CBC: Create request for consented accounts
+CBC -> ASPSP_API: Request data for consented accounts
ASPSP_API -> ASPSP_API: Retrieve data for consented accounts
-BIA <-- ASPSP_API: Return data for consented accounts
-BIA -> BIA: Apply correct permissions to response data
-API_GATEWAY <-- BIA: Return response
-
-end alt
-
-else Filtering is performed on API Gateway
-
-note right of API_GATEWAY
-The assumption here is that the API Gateway will
-connect to the Core Banking Applications
-directly.
-|||
-Note this approach works fine where low volumes of transactions
-are expected. However in scenarios where a high volume
-is expected it may not be hugely efficient i.e. lots
-more data is returned to the gateway, then filtered.
-Unless the API Gateway has some means for managing state
-this may also make pagination difficult.
-end note
-
-API_GATEWAY -> ASPSP_API: Request target accounts
-ASPSP_API -> ASPSP_API: Retrieve data for consented accounts
-API_GATEWAY <-- ASPSP_API: Return response
-API_GATEWAY -> API_GATEWAY: Apply permissions
+CBC <-- ASPSP_API: Return data for consented accounts
+CBC -> CBC: Apply correct permissions to response data
+API_GATEWAY <-- CBC: Return response
end alt
end alt
diff --git a/static/Images/AI-Env-Property-Details.png b/static/Images/AI-Env-Property-Details.png
new file mode 100644
index 00000000..99fef819
Binary files /dev/null and b/static/Images/AI-Env-Property-Details.png differ
diff --git a/static/Images/AI-Manager-Certificates.png b/static/Images/AI-Manager-Certificates.png
new file mode 100644
index 00000000..169649ed
Binary files /dev/null and b/static/Images/AI-Manager-Certificates.png differ
diff --git a/static/Images/AI-Manager-Environments.png b/static/Images/AI-Manager-Environments.png
new file mode 100644
index 00000000..facddab2
Binary files /dev/null and b/static/Images/AI-Manager-Environments.png differ
diff --git a/static/Images/AI-Update-Environment-Properties.png b/static/Images/AI-Update-Environment-Properties.png
new file mode 100644
index 00000000..d3f646d8
Binary files /dev/null and b/static/Images/AI-Update-Environment-Properties.png differ
diff --git a/static/Images/AS-Configure-IdP.png b/static/Images/AS-Configure-IdP.png
new file mode 100644
index 00000000..058290a5
Binary files /dev/null and b/static/Images/AS-Configure-IdP.png differ
diff --git a/static/Images/AS-IdP-User-Mapper.png b/static/Images/AS-IdP-User-Mapper.png
new file mode 100644
index 00000000..5486e3d3
Binary files /dev/null and b/static/Images/AS-IdP-User-Mapper.png differ
diff --git a/static/Images/AS-IdPs.png b/static/Images/AS-IdPs.png
new file mode 100644
index 00000000..6cd36ebd
Binary files /dev/null and b/static/Images/AS-IdPs.png differ
diff --git a/static/Images/Applying_Consent_Sequence.svg b/static/Images/Applying_Consent_Sequence.svg
index f5edc8f0..e5eaa6ea 100644
--- a/static/Images/Applying_Consent_Sequence.svg
+++ b/static/Images/Applying_Consent_Sequence.svg
@@ -1,119 +1 @@
- Open Banking APIs Identity and Access Control Core Banking Applications Data Recipient API Gateway Backend Integration Application Identity Management Banking Systems Overview Filtering responses for account/permissions at the Gateway is pragmatic in many use cases but is ultimately not scaleable due to load and determinism for features such as pagination. It should therefore be implemented as close to the system of record as possible i.e. Core Banking Applications. The order of preference in terms of solutions is: 1. Filter at the Core Banking Application. 2. Filter at a microservice capable of "stateful" behaviour. 3. Filter at the Gateway. Request Account Information Resource with valid Access Token Call Access Token Introspect Endpoint Return introspection information Inspect request alt [DR does not have Consent for the requested account or resource] In some cases the permissions are binary i.e. the DR does or does not have permission to access a given endpoint. In such cases the Gateway can immediately respond without going to the backend. Respond with 403 (Forbidden) [DR has Consent to access requested resource] alt [Filtering is performed outside Gateway] Augment request with consented accounts/permissions alt [Filtering is performed at Core Banking Application] Forward request with consented accounts/permissions Create request for consented accounts Request data for consented accounts Retrieve data for consented accounts Apply permissions to requested data Return data for consented accounts Return response [Filtering is performed at Backend Integration Application] Forward request with consented accounts/permissions Create request for consented accounts Request data for consented accounts Retrieve data for consented accounts Return data for consented accounts Apply correct permissions to response data Return response [Filtering is performed on API Gateway] The assumption here is that the API Gateway will connect to the Core Banking Applications directly. Note this approach works fine where low volumes of transactions are expected. However in scenarios where a high volume is expected it may not be hugely efficient i.e. lots more data is returned to the gateway, then filtered. Unless the API Gateway has some means for managing state this may also make pagination difficult. Request target accounts Retrieve data for consented accounts Return response Apply permissions Format response for standards Return response
\ No newline at end of file
+ Amplify Integration Identity and Access Control Core Banking Applications Data Recipient API Gateway Core Banking Connector Identity Management Banking Systems Overview Filtering responses for account/permissions at the Gateway is pragmatic in many use cases but is ultimately not scaleable due to load and determinism for features such as pagination. It should therefore be implemented as close to the system of record as possible i.e. Core Banking Applications. The order of preference in terms of solutions is: 1. Filter at the Core Banking Application. 2. Filter at a microservice capable of "stateful" behaviour. 3. Filter at the Gateway. Request Account Information Resource with valid Access Token Call JWKS Endpoint to validate JWT access token Return JWKS Validate token and get claims In some cases the permissions are binary i.e. the DR does or does not have permission to access a given endpoint. In such cases the Gateway can immediately respond without going to the backend. Respond with 403 (Forbidden) alt [Filtering is performed outside Gateway] Augment request with consented accounts/permissions alt [Filtering is performed at Core Banking Application] Forward request with consented accounts/permissions Create request for consented accounts Request data for consented accounts Retrieve data for consented accounts Apply permissions to requested data Return data for consented accounts Return response [Filtering is performed at Core Banking Connector] Forward request with consented accounts/permissions Create request for consented accounts Request data for consented accounts Retrieve data for consented accounts Return data for consented accounts Apply correct permissions to response data Return response Format response for standards Return response
\ No newline at end of file
diff --git a/static/Images/CIBA_Example_Sequence.svg b/static/Images/CIBA_Example_Sequence.svg
index f221c11e..ce904c18 100644
--- a/static/Images/CIBA_Example_Sequence.svg
+++ b/static/Images/CIBA_Example_Sequence.svg
@@ -1,904 +1 @@
- Infrastructure Identity and Access Control Open Banking APIs Core Banking Applications Data Recipient App Ingress Controller API Gateway Identity Management --- Authorisation Server Consent Management Bacend Integration Application Banking Identity Provider Banking Systems Open Banking Directory --- JSON Web Key Set Certificate Authority --- OCSP Endpoint Mobile Banking App Customer Part 0: Registration of Token Delivery Preferences CIBA requires that Clients register a delivery mode prior to the transmission of any Authentication Requests: Clients registering to use CIBA MUST indicate a token delivery mode The Authorization Server (AS) therefore must host a registration endpoint - defined in the discoverable OpenID Configuration - that allows the Client to do so. The parameters for this call are described in the CIBA specification and differ depending on the method in question. The modes are: Poll : Client polls the Token endpoint. Ping : AS notifies, Client retrieves from Token endpoint. Push : AS sends tokens to Client. The supported modes vary by AS as they are implementor specific i.e. implementors of the AS can choose to only support one-or-more given modes. The supported modes must be made pushed in the AS OpenID Configuration. POST /connect/register The Kubernetes Ingress Controller is responsible for TLS termination and perfoming an OCSP call to the Certificate Authority to ensure the client certificate presented is valid. The fingerprint of the certificate will be forwarded to Identity Management to verify the validity of the OAuth Client as this cannot be asserted via OCSP. Check Client Certificate Validity Response Registration Request Verify Client Store Client Parameters Response Response Part 1: Create Consent and Send Authentication Request The Data Recipient App requests an Access Token using the Client Credentials grant type. Nominally authentication is through Mutual Authentication over TLS but it could equally be using private_key_jwt . POST /oauth2/token Check Client Certificate Validity Response POST /oauth2/token Verify Client 200 OK {"access_token": "..."} 200 OK {"access_token": "..."} With the Access Token in hand the Data Recipient can then create the consent resource. This needs to be completed before the Authentication Request as the value of the consentId is required to set the value of the scope. POST /payments/v1/consents Check Client Certificate Validity Response POST /payments/v1/consents POST /payments/v1/consents Validate consent request properties 201 Created {consentId: "..."} 201 Created {consentId: "..."} 201 Created {consentId: "..."} The Data Recipient App can now create and send the Authentication Request. This includes the dynamic scope that holds the value of the consentId returned by Identity Management. Create Authentication Request POST /bc-authorize Check Client Certificate Validity Response POST /bc-authorize As with the redirection-based FAPI profiles the Authentication Request is a JSON Web Signature. It therefore needs to be checked for validity. Note that in the context of CIBA Pushed Authorization Request is not required as the Authentication Request is always sent via a secured backchannel and never through the browser. Get JSON Web Key Set Response Match Authentication Request parameter kid Verify Authentication Request parameter signature Validate Authentication Request Note this approach is non-normative and the actual implementation required should be considered on a case-by-case basis. Send Authentication Request notification 201 Created {auth_req_id: "..."} 201 Created {auth_req_id: "..."} Part 2: Customer Authenticates at Mobile Banking App The flow shown is a hypothetical approach to allowing the End User to authenticate and confirm consent. In this scenario has installed their mobile banking app and can receive and act-on a request to authenticate and confirm consent. Correlate Authentication Request with Customer Trigger push notification to Customer The push notification needs to carry some context. For example, the consentId - to require the consent to be correlated correctly. Send push notification to mobile banking app Notify Customer Tap notification Request biometric gesture to authenticate Present biometric gesture As with the majority of mobile banking apps authentication in this example is outsourced to the mobile operating system. Once the customer has authenticated the mobile banking app simply sends a "user authenticated" notification to the IDP. This flow is non-normative, implementation-specific and would be created based on the implementors architecture and technology. User authenticated notification Acknowledgement Request Customer accounts Response Part 3: Customer Confirms Consent and Selects Account As Consent needs to be retrieved from a hostile security zone i.e. from a Customer's mobile device the request to Consent Management should be routed via the Ingress Controller/API Gateway. This flow is implementation-specific and would be created based on the implementors architecture and technology. In this example the Customer is the sole account holder and therefore no further authorizations are required. Retrieve consent Retrieve consent Retrieve consent Retrieve Consent Response Response Response The Consent Confirmation screen requires the following properties to be displayed: Transaction Value. Recipient details (name, in Brazil CPF/CNPJ). Payment Date. Payment method (for example, in Brazil it is fixed as PIX). Fee amount charged by the bank (if any). par [Request fee amount for payment] Fees for payment must be provided from the Banking Systems Request fee amount Response alt [Debtor account not provided in Consent] If the debtor account has not been provided in the Consent then the customer's payment accounts will need to be retrieved: If the customer only has one payment account then this is the default. If they have multiple accounts they should be able to select one. This should be incorporated into the Consent Confirmation screen. Query account list for payment accounts [Debtor account provided in Consent] If the debtor account has already been provided ownership of the account by the customer must be verified. In this example this can be done at the Mobile Banking App as it has already retrieved the list of customer accounts. Verify debtor account ownership Render consent confirmation screen Request consent confirmation Confirm consent Update consent as authorized Update consent as authorized Update consent Update Consent Response Response Response The final step is to call the Identity Management component to indicate that the Customer has been authenticated. Identity Management will then signal to the Data Recipient App using the chosen mode that authentication is complete. Again this flow is implementation-specific and would be created based on the implementors architecture and technology. Authentication complete notification Part 4: Client Granted Access Token Notes on Token behaviors The Data Recipient App is made aware of the success of the based on their registered delivery mode. Each of these is shown below. Note that the Poll looping example is purely illustrative as the Data Recipient App would poll as soon as they received the auth_req_id from the AS. Writing the diagram to incorporate this sequentially would, however be extremely confusing hence the sequence shown below. For Poll and Ping mode the Data Recipient App must use the CIBA grant type as described in the source specification. alt [Client Registered Poll Mode] In Poll mode the DR will periodically call the Token endpoint until they get a positive response i.e. they do not receive the 400 HTTP response code but instead are returned one-or-more tokens (Access, Refresh, ID) from the Token endpoint. loop [Exit when Authentication Request successful] POST /token auth_req_id=... Check Client Certificate Validity Response POST /token auth_req_id=... Retrieve Authentication request Check status 400 Bad Request {...} 400 Bad Request {...} POST /token auth_req_id=... Check Client Certificate Validity Response POST /token auth_req_id=... Retrieve Authentication request Check status Create tokens 200 OK {...} 200 OK {...} [Client Registered Ping Mode] Ping mode is a simple notification by the AS to a callback URL pre-registered by the Data Recipient App in Part 0. On receipt the Data Recipient App can then call the Token endpoint in the same way as in Poll mode and collect one-or-more tokens. Authentication Request complete notification 204 No Content POST /token auth_req_id=... Check Client Certificate Validity Response POST /token auth_req_id=... Retrieve Authentication request Create tokens 200 OK {...} 200 OK {...} [Client Registered Push Mode] In Push mode tokens are created by the AS and then transmitted to the Data Recipient App, therefore negating the need for them to visit the Token endpoint. Their are various implications of using this method which are discussed in the specification . Retrieve Authentication request Create tokens Retrieve callback URL and security token for Data Recipient App POST /cb {...} 204 No Content Part 5: DR Makes Payment Instruction Request With the Access Token in hand the Data Recipient App can now make the payment instruction request. The Access Token is bound to this single operation and will be revoked once the payment instruction is successfully transmitted. POST /payments/v1/pix/payments Check Client Certificate Validity Response POST /payments/v1/pix/payments The approach to Access Token introspection remains the same under payments i.e. the API Gateway will need an assertion that indicates the consent granted by the Customer matches the payment being instructed. Request Access Token properties Retrieve Access Token properties Response Introspect Access Token properties On introspecting the Access Token the API Gateway will decorate the request with the debtor account which is stored with the Consent. This can then be forwarded to the Backend Integration Application and used to make the correct payment instruction in the Banking Systems. Decorate request with debtor account POST /payments/v1/pix/payments This flow is non-normative and will vary on customer requirements. It could be to a PIX-compliant API or any other available mechanism to make a PIX payment. Mediate request payload Deliver payment instruction to Banking System API Response Mediate response payload 201 Created {paymentId: "..."} 201 Created {paymentId: "..."} 201 Created {paymentId: "..."}
\ No newline at end of file
+ Amplify Integration Identity and Access Control Core Banking Applications Data Recipient App API Gateway Consent Management Core Banking Connector Identity Management --- Authorization Server Banking Identity Provider Banking Systems Open Banking Directory --- JSON Web Key Set Certificate Authority --- OCSP Endpoint Mobile Banking App Customer Part 0: Registration of Token Delivery Preferences CIBA requires that Clients register a delivery mode prior to the transmission of any Authentication Requests: Clients registering to use CIBA MUST indicate a token delivery mode The Authorization Server (AS) therefore must host a registration endpoint - defined in the discoverable OpenID Configuration - that allows the Client to do so. The parameters for this call are described in the CIBA specification and differ depending on the method in question. The modes are: Poll : Client polls the Token endpoint. Ping : AS notifies, Client retrieves from Token endpoint. Push : AS sends tokens to Client. The supported modes vary by AS as they are implementor specific i.e. implementors of the AS can choose to only support one-or-more given modes. The supported modes must be made pushed in the AS OpenID Configuration. POST /connect/register The API Gateway is responsible for TLS termination and perfoming an OCSP call to the Certificate Authority to ensure the client certificate presented is valid. The fingerprint of the certificate will be forwarded to Identity Management to verify the validity of the OAuth Client as this cannot be asserted via OCSP. Check Client Certificate Validity Response Registration Request Verify Client Store Client Parameters Response Response Part 1: Create Consent and Send Authentication Request The Data Recipient App requests an Access Token using the Client Credentials grant type. Nominally authentication is through Mutual Authentication over TLS but it could equally be using private_key_jwt . POST /oauth2/token Check Client Certificate Validity Response POST /oauth2/token Verify Client 200 OK {"access_token": "..."} 200 OK {"access_token": "..."} With the Access Token in hand the Data Recipient can then create the consent resource. This needs to be completed before the Authentication Request as the value of the consentId is required to set the value of the scope. POST /payments/v1/consents Check Client Certificate Validity Response POST /payments/v1/consents POST /payments/v1/consents Validate consent request properties 201 Created {consentId: "..."} API_GATEWAY 201 Created {consentId: "..."} The Data Recipient App can now create and send the Authentication Request. This includes the dynamic scope that holds the value of the consentId returned by Identity Management. Create Authentication Request POST /bc-authorize Check Client Certificate Validity Response POST /bc-authorize As with the redirection-based FAPI profiles the Authentication Request is a JSON Web Signature. It therefore needs to be checked for validity. Note that in the context of CIBA Pushed Authorization Request is not required as the Authentication Request is always sent via a secured backchannel and never through the browser. Get JSON Web Key Set Response Match Authentication Request parameter kid Verify Authentication Request parameter signature Validate Authentication Request Note this approach is non-normative and the actual implementation required should be considered on a case-by-case basis. Send Authentication Request notification 201 Created {auth_req_id: "..."} 201 Created {auth_req_id: "..."} Part 2: Customer Authenticates at Mobile Banking App The flow shown is a hypothetical approach to allowing the End User to authenticate and confirm consent. In this scenario has installed their mobile banking app and can receive and act-on a request to authenticate and confirm consent. Correlate Authentication Request with Customer Trigger push notification to Customer The push notification needs to carry some context. For example, the consentId - to require the consent to be correlated correctly. Send push notification to mobile banking app Notify Customer Tap notification Request biometric gesture to authenticate Present biometric gesture As with the majority of mobile banking apps authentication in this example is outsourced to the mobile operating system. Once the customer has authenticated the mobile banking app simply sends a "user authenticated" notification to the IDP. This flow is non-normative, implementation-specific and would be created based on the implementors architecture and technology. User authenticated notification Acknowledgement Request Customer accounts Response Part 3: Customer Confirms Consent and Selects Account As Consent needs to be retrieved from a hostile security zone i.e. from a Customer's mobile device the request to Consent Management should be routed via the Ingress Controller/API Gateway. This flow is implementation-specific and would be created based on the implementors architecture and technology. In this example the Customer is the sole account holder and therefore no further authorizations are required. Retrieve consent Retrieve consent Retrieve Consent Response Response The Consent Confirmation screen requires the following properties to be displayed: Transaction Value. Recipient details (name, in Brazil CPF/CNPJ). Payment Date. Payment method (for example, in Brazil it is fixed as PIX). Fee amount charged by the bank (if any). par [Request fee amount for payment] Fees for payment must be provided from the Banking Systems Request fee amount Response alt [Debtor account not provided in Consent] If the debtor account has not been provided in the Consent then the customer's payment accounts will need to be retrieved: If the customer only has one payment account then this is the default. If they have multiple accounts they should be able to select one. This should be incorporated into the Consent Confirmation screen. Query account list for payment accounts [Debtor account provided in Consent] If the debtor account has already been provided ownership of the account by the customer must be verified. In this example this can be done at the Mobile Banking App as it has already retrieved the list of customer accounts. Verify debtor account ownership Render consent confirmation screen Request consent confirmation Confirm consent Update consent as authorized Update consent Update Consent Response Response The final step is to call the Identity Management component to indicate that the Customer has been authenticated. Identity Management will then signal to the Data Recipient App using the chosen mode that authentication is complete. Again this flow is implementation-specific and would be created based on the implementors architecture and technology. Authentication complete notification Part 4: Client Granted Access Token Notes on Token behaviors The Data Recipient App is made aware of the success of the based on their registered delivery mode. Each of these is shown below. Note that the Poll looping example is purely illustrative as the Data Recipient App would poll as soon as they received the auth_req_id from the AS. Writing the diagram to incorporate this sequentially would, however be extremely confusing hence the sequence shown below. For Poll and Ping mode the Data Recipient App must use the CIBA grant type as described in the source specification. alt [Client Registered Poll Mode] In Poll mode the DR will periodically call the Token endpoint until they get a positive response i.e. they do not receive the 400 HTTP response code but instead are returned one-or-more tokens (Access, Refresh, ID) from the Token endpoint. loop [Exit when Authentication Request successful] POST /token auth_req_id=... Check Client Certificate Validity Response POST /token auth_req_id=... Retrieve Authentication request Check status 400 Bad Request {...} 400 Bad Request {...} POST /token auth_req_id=... Check Client Certificate Validity Response POST /token auth_req_id=... Retrieve Authentication request Check status Create tokens 200 OK {...} 200 OK {...} [Client Registered Ping Mode] Ping mode is a simple notification by the AS to a callback URL pre-registered by the Data Recipient App in Part 0. On receipt the Data Recipient App can then call the Token endpoint in the same way as in Poll mode and collect one-or-more tokens. Authentication Request complete notification 204 No Content POST /token auth_req_id=... Check Client Certificate Validity Response POST /token auth_req_id=... Retrieve Authentication request Create tokens 200 OK {...} 200 OK {...} [Client Registered Push Mode] In Push mode tokens are created by the AS and then transmitted to the Data Recipient App, therefore negating the need for them to visit the Token endpoint. Their are various implications of using this method which are discussed in the specification . Retrieve Authentication request Create tokens Retrieve callback URL and security token for Data Recipient App POST /cb {...} 204 No Content Part 5: DR Makes Payment Instruction Request With the Access Token in hand the Data Recipient App can now make the payment instruction request. The Access Token is bound to this single operation and will be revoked once the payment instruction is successfully transmitted. POST /payments/v1/pix/payments Check Client Certificate Validity Response The approach to Access Token introspection remains the same under payments i.e. the API Gateway will need an assertion that indicates the consent granted by the Customer matches the payment being instructed. Request Access Token properties Retrieve Access Token properties Response Introspect Access Token properties On introspecting the Access Token the API Gateway will decorate the request with the debtor account which is stored with the Consent. This can then be forwarded to the Core Banking Connector and used to make the correct payment instruction in the Banking Systems. Decorate request with debtor account POST /payments/v1/pix/payments This flow is non-normative and will vary on customer requirements. It could be to a PIX-compliant API or any other available mechanism to make a PIX payment. Mediate request payload Deliver payment instruction to Banking System API Response Mediate response payload 201 Created {paymentId: "..."} 201 Created {paymentId: "..."}
\ No newline at end of file
diff --git a/static/Images/FDX-Workflow.svg b/static/Images/FDX-Workflow.svg
new file mode 100644
index 00000000..0ec292dd
--- /dev/null
+++ b/static/Images/FDX-Workflow.svg
@@ -0,0 +1,4 @@
+
+
+
+Resource APIs
(Amplify Integration)
2c. Redirect for approval
2. Authorize Consent (/authorize)
2g. Update Consent Resources
Legend Consent Management
(Amplify Integration)
Core Banking Connector
(Amplify Integration)
Business / Consumer Insights
2d. Fetch consent permissions
\ No newline at end of file
diff --git a/static/Images/FDX_Web_Journey_Sequence.svg b/static/Images/FDX_Web_Journey_Sequence.svg
index b488eb33..a205fa84 100644
--- a/static/Images/FDX_Web_Journey_Sequence.svg
+++ b/static/Images/FDX_Web_Journey_Sequence.svg
@@ -1,302 +1 @@
- Infrastructure Identity and Access Control Open Banking APIs Core Banking Applications End User Data Recipient Ingress Controller API Gateway Identity Management --- Authorisation Server Consent Management Backend Integration Application Banking Identity Provider Banking Systems Overview This diagram shows the end-to-end web journey for obtaining Consent and starting to collect Account Information data. The goal is to place the components from the Architecture Overview in context. Part 1: DR Obtains End User Consent Obtaining Consent from the End User is usually outside the scope of technical standards. The Customer Experience Guidelines in FDX informs how Consent should be displayed and obtained. The specifics of this process are therefore not shown here. The Data Recipient (DR) is assumed to have implemented this within the guidelines specified. Indicate wish to share data Display "Intent" i.e. data to be accessed or payment to be made Confirm intent Show bank selection screen Confirm bank selection Part 2: DR Creates and Lodges "Intent" With the consent of the End User obtained the DR can now call the Authorization Server API at the correct bank. Note at this point Consent is usual termed "Intent" as it hasyet to confirmed at the bank. Create Intent payload Send Push Authorization Request The par request MUST contain an authorization details parameter { "authorization_details": [ { "type": "fdx_v1.0", "consentRequest": { "durationType": "ONETIME", "lookbackPeriod": 60, "resources": [ { "resourceType": "ACCOUNT", "dataClusters": [ "ACCOUNT_DETAILED", "TRANSACTIONS", "STATEMENTS" ] } ] } } ] } POST /par "{"authorization_details":[{"type":"fdx_v1.0","consentRequest":"...."}] " return request_uri Part 3: User authentication, consent and authorization Send Authorization Request GET /authorize&request_uri= REDIRECT /login USER login 200 OK {...} Serve Consent and Account Confirmation Screen Serve Consent and Account Confirmation Screen "Consent confirmation is correct 201 CREATED {"consentId":"..."} 200 OK {"code":"..."} The DR then obtains the Access Token using the Authorization Code POST /token Verify Client 200 OK {"access_token": "..."} Part 4: Request Data Account Information DRs use a generic endpoint for Account Information that covers all account types (checking, credit card, loans, etc). GET /fdx/{version}/core/accounts Introspect Access Token POST /token-introspection 200 OK {"status": "..."} Verify Access Token scope GET /fdx/{version}/core/accounts GET /fdx/{version}/core/accounts 200 OK {"accounts": "..."} 200 OK {"accounts": "..."} 200 OK {"accounts": "..."}
\ No newline at end of file
+ Amplify Integration Identity and Access Control Core Banking Applications End User Data Recipient API Gateway Consent Management Core Banking Connector Identity Management --- Authorization Server Consent Grant App Banking Identity Provider Banking Systems Overview This diagram sh ows the end-to-end web journey for obtaining Consent and starting to collect Account Information data. The goal is to place the components from the Architecture Overview in context. Part 1: DR Obtains End User Consent Obtaining Consent from the End User is usually outside the scope of technical standards. The Customer Experience Guidelines in FDX informs how Consent should be displayed and obtained. The specifics of this process are therefore not shown here. The Data Recipient (DR) is assumed to have implemented this within the guidelines specified. Indicate wish to share data Display "Intent" i.e. data to be accessed or payment to be made Confirm intent Show bank selection screen Confirm bank selection Part 2: DR Creates and Lodges "Intent" With the consent of the End User obtained the DR can now call the Authorization Server API at the correct bank. Note at this point Consent is usual termed "Intent" as it has yet to be confirmed at the bank. Create Intent payload Send Push Authorization Request The par request MUST contain an authorization details parameter { "authorization_details": [ { "type": "fdx_v1.0", "consentRequest": { "durationType": "ONE_TIME", "lookbackPeriod": 60, "resources": [ { "resourceType": "ACCOUNT", "dataClusters": [ "ACCOUNT_DETAILED", "TRANSACTIONS" ] } ] } } ] } POST /par "{"authorization_details":[{"type":"fdx_v1.0","consentRequest":"...."}] " Validate certificate POST /par "{"authorization_details":[{"type":"fdx_v1.0","consentRequest":"...."}] " return request_uri Create consent Consent created return request_uri Part 3: User authentication, consent and authorization Send Authorization Request GET /authorize&request_uri= REDIRECT /login USER login 200 OK {...} Serve Consent and Account Confirmation Screen Serve Consent and Account Confirmation Screen "Consent confirmation is correct Update consent resources and status Consent updated Redirect with success 200 OK {"code":"..."} The DR then obtains the Access Token using the Authorization Code POST /token Verify Client 200 OK {"access_token": "..."} Part 4: Request Data Account Information DRs use a generic endpoint for Account Information that covers all account types (checking, credit card, loans, etc). GET /fdx/{version}/core/accounts Validate Access Token Verify Access Token claims GET /fdx/{version}/core/accounts GET /fdx/{version}/core/accounts 200 OK {"accounts": "..."} 200 OK {"accounts": "..."} 200 OK {"accounts": "..."}
\ No newline at end of file
diff --git a/static/Images/FDX_Workflow.png b/static/Images/FDX_Workflow.png
deleted file mode 100644
index 6f3d7a16..00000000
Binary files a/static/Images/FDX_Workflow.png and /dev/null differ
diff --git a/static/Images/FDX_Workflow_0.png b/static/Images/FDX_Workflow_0.png
deleted file mode 100644
index afe13fb1..00000000
Binary files a/static/Images/FDX_Workflow_0.png and /dev/null differ
diff --git a/static/Images/Infrastructure_View.jpg b/static/Images/Infrastructure_View.jpg
deleted file mode 100644
index 4aa98748..00000000
Binary files a/static/Images/Infrastructure_View.jpg and /dev/null differ
diff --git a/static/Images/Infrastructure_View_0.png b/static/Images/Infrastructure_View_0.png
deleted file mode 100644
index 98b37ae1..00000000
Binary files a/static/Images/Infrastructure_View_0.png and /dev/null differ
diff --git a/static/Images/Integration-Overview.svg b/static/Images/Integration-Overview.svg
new file mode 100644
index 00000000..d40a6aee
--- /dev/null
+++ b/static/Images/Integration-Overview.svg
@@ -0,0 +1,4 @@
+
+
+
+
\ No newline at end of file
diff --git a/static/Images/Integration_Overview_0.svg b/static/Images/Integration_Overview_0.svg
deleted file mode 100644
index 07042946..00000000
--- a/static/Images/Integration_Overview_0.svg
+++ /dev/null
@@ -1,2 +0,0 @@
-
\ No newline at end of file
diff --git a/static/Images/Integration_Overview_OBB.png b/static/Images/Integration_Overview_OBB.png
deleted file mode 100644
index d78801c2..00000000
Binary files a/static/Images/Integration_Overview_OBB.png and /dev/null differ
diff --git a/static/Images/Mutual_Authentication_Sequence.svg b/static/Images/Mutual_Authentication_Sequence.svg
index 316503b7..42413bec 100644
--- a/static/Images/Mutual_Authentication_Sequence.svg
+++ b/static/Images/Mutual_Authentication_Sequence.svg
@@ -1,146 +1 @@
- Infrastructure Open Banking APIs Identity and Access Control Core Banking Applications Data Recipient Ingress Controller API Gateway Backend Integration Application Identity Management Market Certificate Authority Banking Systems This diagram shows the specifics of mutual authentication as implemented in the open banking accelerator. Request protected endpoint Validate certificate chain Request protected endpoint Check certificate status (OCSP/CRL) Response alt [Certificate binding is enforced] Binding the Access Token to a given client certificate is enforced through FAPI which references RFC 8705 . To support this the API Gateway uses the Access Token introspection endpoint to retrieve the stored certificate fingerprint. Access Token introspection Retrieve Access Token properties Response Calculate certificate fingerprint Compare stored and calculated fingerprints Request protected endpoint Request backend data or service Response Response Response Response
\ No newline at end of file
+ Amplify Integration Identity and Access Control Core Banking Applications Data Recipient API Gateway Core Banking Connector Authorization Server Market Certificate Authority Banking Systems This diagram shows the specifics of mutual authentication as implemented in the open banking accelerator. Request protected endpoint Validate certificate chain Check certificate status (OCSP/CRL) Response alt [Certificate binding is enforced] Binding the Access Token to a given client certificate is enforced through FAPI which references RFC 8705 . To support this the API Gateway uses the JWT claims to retrieve the stored certificate fingerprint. Call JWKS Endpoint to validate JWT access token Return JWKS Get claims from JWT Calculate certificate fingerprint Compare stored and calculated fingerprints Request protected endpoint Request backend data or service Response Response
\ No newline at end of file
diff --git a/static/Images/Solution-Building-Blocks.svg b/static/Images/Solution-Building-Blocks.svg
new file mode 100644
index 00000000..b45998c2
--- /dev/null
+++ b/static/Images/Solution-Building-Blocks.svg
@@ -0,0 +1,4 @@
+
+
+
+The means for developers to work with your APIs with the minimal amount of effort.
Provides the means to achieve compliance with standards whilst integrating with your backend applications.
Provides security, authentication and authorization through consent and compliance with security protocols defined by standards.
Identity and Access Control
Solution is underpinned by Axway's Amplify Integration which provides the basis of all other building blocks.
Provides the data and services that open banking use cases are built upon
Core Banking Applications
\ No newline at end of file
diff --git a/static/Images/Solution-Overview.svg b/static/Images/Solution-Overview.svg
new file mode 100644
index 00000000..e1f6711c
--- /dev/null
+++ b/static/Images/Solution-Overview.svg
@@ -0,0 +1,4 @@
+
+
+
+API Product Catalog and documentation
Marketplace Administration
Connect with Existing Gateways
Usage plans and Subscriptions
Developer and Organization Onboarding
Application and
Credential Management
Subscriptions, Application and API Usage
Access to Account for Data
Access to Account for Payments
Identity and Access Control
Core Banking Applications
Core Banking Applications
\ No newline at end of file
diff --git a/static/Images/Solution_Building_Blocks.png b/static/Images/Solution_Building_Blocks.png
deleted file mode 100644
index feb5a5e6..00000000
Binary files a/static/Images/Solution_Building_Blocks.png and /dev/null differ
diff --git a/static/Images/Solution_Building_Blocks.svg b/static/Images/Solution_Building_Blocks.svg
deleted file mode 100644
index 0284e114..00000000
--- a/static/Images/Solution_Building_Blocks.svg
+++ /dev/null
@@ -1,2 +0,0 @@
-
\ No newline at end of file
diff --git a/static/Images/Solution_Building_Blocks_bkp.svg b/static/Images/Solution_Building_Blocks_bkp.svg
deleted file mode 100644
index 4acbead3..00000000
--- a/static/Images/Solution_Building_Blocks_bkp.svg
+++ /dev/null
@@ -1,2 +0,0 @@
-
\ No newline at end of file
diff --git a/static/Images/Solution_Overview.png b/static/Images/Solution_Overview.png
deleted file mode 100644
index 1962e58b..00000000
Binary files a/static/Images/Solution_Overview.png and /dev/null differ
diff --git a/static/Images/Solution_Overview.svg b/static/Images/Solution_Overview.svg
deleted file mode 100644
index fb92861a..00000000
--- a/static/Images/Solution_Overview.svg
+++ /dev/null
@@ -1,2 +0,0 @@
-Customer Infrastructure ( On - Premise , Cloud or Hybrid ) Kubernetes API Catalog and documentation Development Tools Developer and Organization Onboarding Application and Credential Management Service Desk and Collaboration Application and API Usage Demo Applications Open Data Developer Experience Access to Account for Data Access to Account for Payments Standards Compliance Open Banking APIs Bank Use Cases Intent Lodging Consent Confirmation FAPI Identity and Access Control Consent Revocation API Portal API Gateway Consent Manage ment Identity Management Infrastructure Analytics Utilities Third - Party Developer Third - Party Apps Open Banking Team API Builder Banking Systems Bank Identity Provider Core Banking Applications Premium APIs Existing Portal Solution
\ No newline at end of file
diff --git a/static/Images/Solution_Overview_0.svg b/static/Images/Solution_Overview_0.svg
deleted file mode 100644
index f4e2c881..00000000
--- a/static/Images/Solution_Overview_0.svg
+++ /dev/null
@@ -1,2 +0,0 @@
-
\ No newline at end of file
diff --git a/static/Images/add_environment_properties.png b/static/Images/add_environment_properties.png
new file mode 100644
index 00000000..22d83516
Binary files /dev/null and b/static/Images/add_environment_properties.png differ
diff --git a/static/Images/client-policies.png b/static/Images/client-policies.png
new file mode 100644
index 00000000..6f7dffb1
Binary files /dev/null and b/static/Images/client-policies.png differ
diff --git a/static/Images/client-scopes.png b/static/Images/client-scopes.png
new file mode 100644
index 00000000..b2da205c
Binary files /dev/null and b/static/Images/client-scopes.png differ
diff --git a/static/Images/component-overview-nextgen.png b/static/Images/component-overview-nextgen.png
new file mode 100644
index 00000000..a2718538
Binary files /dev/null and b/static/Images/component-overview-nextgen.png differ
diff --git a/static/Images/consent-grant-redirect.png b/static/Images/consent-grant-redirect.png
new file mode 100644
index 00000000..68ea69ac
Binary files /dev/null and b/static/Images/consent-grant-redirect.png differ
diff --git a/static/Images/end-user-update.png b/static/Images/end-user-update.png
new file mode 100644
index 00000000..98d96a0d
Binary files /dev/null and b/static/Images/end-user-update.png differ
diff --git a/static/Images/fdx-resource.png b/static/Images/fdx-resource.png
new file mode 100644
index 00000000..63d57651
Binary files /dev/null and b/static/Images/fdx-resource.png differ
diff --git a/static/Images/identity-providers.png b/static/Images/identity-providers.png
new file mode 100644
index 00000000..182bbb06
Binary files /dev/null and b/static/Images/identity-providers.png differ
diff --git a/static/Images/import_collection.png b/static/Images/import_collection.png
new file mode 100644
index 00000000..4f1dd3fa
Binary files /dev/null and b/static/Images/import_collection.png differ
diff --git a/static/Images/import_collection_set_env.png b/static/Images/import_collection_set_env.png
new file mode 100644
index 00000000..f8b23bd9
Binary files /dev/null and b/static/Images/import_collection_set_env.png differ
diff --git a/static/Images/import_collection_step2.png b/static/Images/import_collection_step2.png
new file mode 100644
index 00000000..bb9c443b
Binary files /dev/null and b/static/Images/import_collection_step2.png differ
diff --git a/static/Images/import_environment.png b/static/Images/import_environment.png
new file mode 100644
index 00000000..f8f5ae82
Binary files /dev/null and b/static/Images/import_environment.png differ
diff --git a/static/Images/mapper.png b/static/Images/mapper.png
new file mode 100644
index 00000000..b9a23b3f
Binary files /dev/null and b/static/Images/mapper.png differ
diff --git a/static/Images/ob-issuer.png b/static/Images/ob-issuer.png
new file mode 100644
index 00000000..7edb1db4
Binary files /dev/null and b/static/Images/ob-issuer.png differ
diff --git a/static/Images/post-login-flow.png b/static/Images/post-login-flow.png
new file mode 100644
index 00000000..c6cb7108
Binary files /dev/null and b/static/Images/post-login-flow.png differ
diff --git a/static/Images/post-login-identity-provider.png b/static/Images/post-login-identity-provider.png
new file mode 100644
index 00000000..1ad6be36
Binary files /dev/null and b/static/Images/post-login-identity-provider.png differ
diff --git a/static/postman-collection/FDX-Demo-postman-collection.json b/static/postman-collection/FDX-Demo-postman-collection.json
new file mode 100644
index 00000000..d434ef12
--- /dev/null
+++ b/static/postman-collection/FDX-Demo-postman-collection.json
@@ -0,0 +1,2257 @@
+{
+ "info": {
+ "_postman_id": "f6b68b15-25db-433a-870a-2b71f16dba5c",
+ "name": "FDX Demo",
+ "description": "This collection implements the FDX Consent Grant Flow as defined in FDX RFC 0156 & allows you to access the Core API endpoints.\n\nHere are the prerequisites to run the requests in this collection:\n\n- API server endpoint is protected with MTLS, so get the certificate & private key from Financial Institution.\n \n- Choose the Environment \"FDX Demo\" from the Environment selector in the top right.\n \n- Use the cog button to open Settings\n \n - Choose the Certificates tab. Ensure a certificate is installed for the target environment. If not click \"Add Certificate\".\n \n - Enter the target host and port and upload the public and private keys (CRT file and KEY file respectively) and click ADD.\n \n- Update the current values in the Environment \"FDX Demo\".\n \n- Follow the instructions for each section/request below.",
+ "schema": "https://schema.getpostman.com/json/collection/v2.1.0/collection.json",
+ "_exporter_id": "236738"
+ },
+ "item": [
+ {
+ "name": "Get Access Token",
+ "item": [
+ {
+ "name": "Auth Sever Metadata",
+ "request": {
+ "method": "GET",
+ "header": [],
+ "url": {
+ "raw": "{{baseUrl}}/fdx/auth/v1/well-known",
+ "host": [
+ "{{baseUrl}}"
+ ],
+ "path": [
+ "fdx",
+ "auth",
+ "v1",
+ "well-known"
+ ]
+ },
+ "description": "The endpoint retrieves the well-known configuration for the Authorization Server. The response is a JSON object with various properties such as issuer, authorization endpoint, token endpoint, and other supported features and methods related to authentication and authorization."
+ },
+ "response": []
+ },
+ {
+ "name": "Step 0.1 - Get jsrsasign-js (One time setup)",
+ "event": [
+ {
+ "listen": "test",
+ "script": {
+ "exec": [
+ "pm.globals.set(\"jsrsasign-js\", pm.response.text());"
+ ],
+ "type": "text/javascript",
+ "packages": {}
+ }
+ }
+ ],
+ "request": {
+ "method": "GET",
+ "header": [],
+ "url": {
+ "raw": "http://kjur.github.io/jsrsasign/jsrsasign-latest-all-min.js",
+ "protocol": "http",
+ "host": [
+ "kjur",
+ "github",
+ "io"
+ ],
+ "path": [
+ "jsrsasign",
+ "jsrsasign-latest-all-min.js"
+ ]
+ },
+ "description": "This endpoint makes an HTTP GET request to retrieve the JavaScript resource file from the specified URL. This is a one time execution step to create a global variable and this variable is needed in next step."
+ },
+ "response": []
+ },
+ {
+ "name": "Step 0.2 - Generate Request Object",
+ "event": [
+ {
+ "listen": "prerequest",
+ "script": {
+ "exec": [
+ "const exp = Math.floor(Date.now() / 1000) + 3600;",
+ "pm.collectionVariables.set(\"exp\", exp);",
+ "",
+ "function generateCodeVerifier() {",
+ " return generateRandomString(96);",
+ "}",
+ "",
+ "function generateRandomString(length) {",
+ " var text = \"\";",
+ " var possible = \"ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789\";",
+ " for (var i = 0; i < length; i++) {",
+ " text += possible.charAt(Math.floor(Math.random() * possible.length));",
+ " }",
+ " return text;",
+ "}",
+ "",
+ "function generateCodeChallenge(code_verifier) {",
+ " return CryptoJS.SHA256(code_verifier);",
+ "}",
+ "",
+ "function base64URL(string) {",
+ " return string.toString(CryptoJS.enc.Base64).replace(/=/g, '').replace(/\\+/g, '-').replace(/\\//g, '_')",
+ "}",
+ "",
+ "var verifier = base64URL(generateCodeVerifier());",
+ "var challenge = base64URL(generateCodeChallenge(verifier));",
+ "",
+ "pm.collectionVariables.set(\"code_verifier\", verifier);",
+ "pm.collectionVariables.set(\"code_challenge\", challenge);"
+ ],
+ "type": "text/javascript",
+ "packages": {}
+ }
+ },
+ {
+ "listen": "test",
+ "script": {
+ "exec": [
+ "token = pm.request.headers.get(\"Authorization\")",
+ "console.log(token);",
+ "pm.collectionVariables.set(\"request_token\", token);"
+ ],
+ "type": "text/javascript",
+ "packages": {}
+ }
+ }
+ ],
+ "protocolProfileBehavior": {
+ "disableBodyPruning": true
+ },
+ "request": {
+ "auth": {
+ "type": "jwt",
+ "jwt": [
+ {
+ "key": "privateKey",
+ "value": "{{privateKey}}",
+ "type": "string"
+ },
+ {
+ "key": "payload",
+ "value": "{\r\n\"iat\": {{$timestamp}},\r\n\"exp\": {{exp}},\r\n\"iss\": \"{{realmName}}\",\r\n\"nbf\": {{$timestamp}},\r\n\"state\": \"{{$guid}}\",\r\n\"aud\": [\"{{baseUrl}}/fdx/auth/v1\"],\r\n\"jti\": \"jwt_nonce\",\r\n\"response_mode\": \"jwt\",\r\n\"redirect_uris\": [\"https://oauth.pstmn.io/v1/callback\"],\r\n\"code_challenge\": \"{{code_challenge}}\",\r\n\"code_challenge_method\": \"S256\",\r\n\"client_id\": \"{{clientId}}\",\r\n\"scope\": \"fdx:accountbasic:read fdx:accountdetailed:read fdx:transactions:read fdx:paymentsupport:read fdx:customercontact:read\",\r\n\"authorization_details\": [\t{\r\n \"type\": \"fdx_v1.0\",\r\n \"consentRequest\": {\r\n \"durationType\": \"TIME_BOUND\",\r\n \"durationPeriod\": 90,\r\n \"lookbackPeriod\": 60,\r\n \"resources\": [ {\r\n \"resourceType\": \"ACCOUNT\",\r\n \"dataClusters\": [ \"ACCOUNT_BASIC\",\"ACCOUNT_DETAILED\",\"TRANSACTIONS\",\r\n \"PAYMENT_SUPPORT\",\r\n \"CUSTOMER_CONTACT\"]\r\n }]\r\n }\r\n}],\r\n\"response_type\": \"code\"\r\n}",
+ "type": "string"
+ },
+ {
+ "key": "headerPrefix",
+ "value": "",
+ "type": "string"
+ },
+ {
+ "key": "addTokenTo",
+ "value": "header",
+ "type": "string"
+ },
+ {
+ "key": "header",
+ "value": "{\r\n\t\"typ\": \"JWT\",\r\n\t\"alg\": \"PS256\"\r\n}",
+ "type": "string"
+ },
+ {
+ "key": "algorithm",
+ "value": "PS256",
+ "type": "string"
+ },
+ {
+ "key": "isSecretBase64Encoded",
+ "value": false,
+ "type": "boolean"
+ },
+ {
+ "key": "queryParamKey",
+ "value": "token",
+ "type": "string"
+ }
+ ]
+ },
+ "method": "GET",
+ "header": [],
+ "body": {
+ "mode": "urlencoded",
+ "urlencoded": []
+ },
+ "url": {
+ "raw": "https://postman-echo.com/get",
+ "protocol": "https",
+ "host": [
+ "postman-echo",
+ "com"
+ ],
+ "path": [
+ "get"
+ ]
+ },
+ "description": "In this step, we create a signed request object which is then sent in the PAR request in next step."
+ },
+ "response": [
+ {
+ "name": "Step 0 - Generate Request Object",
+ "originalRequest": {
+ "method": "GET",
+ "header": [],
+ "url": {
+ "raw": "https://postman-echo.com/get",
+ "protocol": "https",
+ "host": [
+ "postman-echo",
+ "com"
+ ],
+ "path": [
+ "get"
+ ]
+ }
+ },
+ "status": "OK",
+ "code": 200,
+ "_postman_previewlanguage": "json",
+ "header": [
+ {
+ "key": "Date",
+ "value": "Wed, 10 Jul 2024 11:42:25 GMT"
+ },
+ {
+ "key": "Content-Type",
+ "value": "application/json; charset=utf-8"
+ },
+ {
+ "key": "Content-Length",
+ "value": "1919"
+ },
+ {
+ "key": "Connection",
+ "value": "keep-alive"
+ },
+ {
+ "key": "Server",
+ "value": "nginx/1.25.3"
+ },
+ {
+ "key": "ETag",
+ "value": "W/\"77f-o8R1MklQA1NDTp5hcOu/dQBurAw\""
+ },
+ {
+ "key": "set-cookie",
+ "value": "sails.sid=s%3AfgeVs-xsiZ-D2zdyihmAxmrs9LfsGZO0.3Qh%2BqjzuHx%2BrRMUyetLj%2FUvZSOFl%2FnAGjM762TPGEdk; Path=/; HttpOnly"
+ }
+ ],
+ "cookie": [],
+ "body": "{\n \"args\": {},\n \"headers\": {\n \"host\": \"postman-echo.com\",\n \"x-request-start\": \"t=1720611745.756\",\n \"x-forwarded-proto\": \"https\",\n \"x-forwarded-port\": \"443\",\n \"x-amzn-trace-id\": \"Root=1-668e73a1-235dfdc26704ac7b2535e560\",\n \"authorization\": \"eyJ0eXAiOiJKV1QiLCJhbGciOiJQUzI1NiJ9.eyJpYXQiOjE3MjA2MTE3NDUsImV4cCI6MTcyMDYxNTM0NSwiaXNzIjoiZ3JpZmZpbi1saXZlIiwibmJmIjoxNzIwNjExNzQ1LCJzdGF0ZSI6IjMxYWI2ZjE0LWU5ZWQtNDFmYS1hOGYxLTQxMDg1NzI2MzRhNiIsImF1ZCI6WyJodHRwczovL2F1dGgub3BlbmJhbmtpbmcuYXh3YXlzYnNkZXYubmV0L3JlYWxtcy9ncmlmZmluLWxpdmUiXSwianRpIjoiand0X25vbmNlIiwicmVzcG9uc2VfbW9kZSI6Imp3dCIsImNvZGVfY2hhbGxlbmdlIjoibElTcXdBMU1Fb2xJQkV0UkF1TU1XY1lJVkNyYnV2MV9Fd0Fab2JfVHlENCIsImNvZGVfY2hhbGxlbmdlX21ldGhvZCI6IlMyNTYiLCJjbGllbnRfaWQiOiJlbW9uZXkiLCJzY29wZSI6ImZkeDphY2NvdW50YmFzaWM6cmVhZCBmZHg6YWNjb3VudGRldGFpbGVkOnJlYWQgZmR4OnRyYW5zYWN0aW9uczpyZWFkIiwiYXV0aG9yaXphdGlvbl9kZXRhaWxzIjpbeyJ0eXBlIjoiZmR4X3YxLjAiLCJjb25zZW50UmVxdWVzdCI6eyJkdXJhdGlvblR5cGUiOiJUSU1FX0JPVU5EIiwiZHVyYXRpb25QZXJpb2QiOjkwLCJsb29rYmFja1BlcmlvZCI6NjAsInJlc291cmNlcyI6W3sicmVzb3VyY2VUeXBlIjoiQUNDT1VOVCIsImRhdGFDbHVzdGVycyI6WyJBQ0NPVU5UX0JBU0lDIiwiQUNDT1VOVF9ERVRBSUxFRCIsIlRSQU5TQUNUSU9OUyJdfV19fV0sInJlc3BvbnNlX3R5cGUiOiJjb2RlIn0.fapsy8--QJEEVJ9tj4ahXpmN3tYJhYqdc5Al_8yQZWJWMHRDloFalTNtgshiTBbAtHrTmafuA5J5k1PVBRH0NMNXVdx2PfL3wDEAzse5GOZ3vl4f550fpDlMzOcKfFdgDQXWMzbhfHb5_ICAv9qwGJt6HAFdB-GfYkV000Bj0yQgTNg0Gul9oRvBjSFzvoDftTflpgXXLZl3apaeaEgvY_fVuVUkEfT7f9mRIEq9e5MKoM2Lx5JjMUHiSFFAO7n6QPlamsW-Bc1xlRi2k9yrrdT3hN-iMdpn2TJYTkd6RquvHfr4cfV3A5dZZJqmunTgceW-iSN3LZ_LSdJWOqK2rg\",\n \"user-agent\": \"PostmanRuntime/7.39.0\",\n \"accept\": \"*/*\",\n \"cache-control\": \"no-cache\",\n \"postman-token\": \"708bea87-9dfe-48b5-99ad-2dca880bded8\",\n \"accept-encoding\": \"gzip, deflate, br\",\n \"cookie\": \"sails.sid=s%3Abf-ZQ4ksobhItz06hUMikagNrY0aUsz-.zEtEY%2F4O2PREYLXKGl07mpiJex42VyJ7Z521q7VlXBk\"\n },\n \"url\": \"https://postman-echo.com/get\"\n}"
+ }
+ ]
+ },
+ {
+ "name": "Step 1 - PAR Request",
+ "event": [
+ {
+ "listen": "prerequest",
+ "script": {
+ "exec": [
+ ""
+ ],
+ "type": "text/javascript",
+ "packages": {}
+ }
+ },
+ {
+ "listen": "test",
+ "script": {
+ "exec": [
+ "pm.test(\"Response status code is 201\", function () {\r",
+ " pm.response.to.have.status(201);\r",
+ "});\r",
+ "\r",
+ "pm.test(\"Response has the required fields - request_uri and expires_in\", function () {\r",
+ " const responseData = pm.response.json();\r",
+ "\r",
+ " pm.expect(responseData).to.be.an('object');\r",
+ " pm.expect(responseData.request_uri).to.exist;\r",
+ " pm.expect(responseData.expires_in).to.exist;\r",
+ "});\r",
+ "\r",
+ "pm.test(\"Expires_in is a non-negative integer\", function () {\r",
+ " const responseData = pm.response.json();\r",
+ " \r",
+ " pm.expect(responseData).to.be.an('object');\r",
+ " pm.expect(responseData.expires_in).to.be.a('number').and.to.be.at.least(0);\r",
+ "});\r",
+ "\r",
+ "// Stores the request_uri in a collection variable\r",
+ "var request_uri = pm.response.json().request_uri;\r",
+ "pm.collectionVariables.set(\"request_uri\", request_uri);\r",
+ "\r",
+ "// const link = '{{baseUrl}}/fdx/auth/v1/authorize?client_id={{client_id}}&request_uri={{request_uri}}';\r",
+ "// pm.visualizer.set(`\r",
+ "// Open this link in browser to login and authorize consent: \r",
+ "// `,\r",
+ "// {\r",
+ "// link: link, \r",
+ "// baseUrl: pm.environment.get('baseUrl'),\r",
+ "// client_id: pm.environment.get('clientId'),\r",
+ "// request_uri: pm.collectionVariables.get('request_uri'),\r",
+ "// })\r",
+ ""
+ ],
+ "type": "text/javascript",
+ "packages": {}
+ }
+ }
+ ],
+ "request": {
+ "method": "POST",
+ "header": [],
+ "body": {
+ "mode": "urlencoded",
+ "urlencoded": [
+ {
+ "key": "request",
+ "value": "{{request_token}}",
+ "type": "text"
+ },
+ {
+ "key": "client_id",
+ "value": "{{clientId}}",
+ "type": "text"
+ }
+ ]
+ },
+ "url": {
+ "raw": "{{baseUrl}}/fdx/auth/v1/par",
+ "host": [
+ "{{baseUrl}}"
+ ],
+ "path": [
+ "fdx",
+ "auth",
+ "v1",
+ "par"
+ ]
+ },
+ "description": "#### **Data Recipient (DR) initiates a POST request to Data Provider's (DP’s) POST /par endpoint using the Pushed Authorization Request (PAR) method**"
+ },
+ "response": [
+ {
+ "name": "Step 1 - PAR Request",
+ "originalRequest": {
+ "method": "POST",
+ "header": [],
+ "body": {
+ "mode": "urlencoded",
+ "urlencoded": [
+ {
+ "key": "request",
+ "value": "{{request_token}}",
+ "type": "text"
+ },
+ {
+ "key": "client_id",
+ "value": "{{clientId}}",
+ "type": "text"
+ }
+ ]
+ },
+ "url": {
+ "raw": "{{baseUrl}}/fdx/auth/v1/par",
+ "host": [
+ "{{baseUrl}}"
+ ],
+ "path": [
+ "fdx",
+ "auth",
+ "v1",
+ "par"
+ ]
+ }
+ },
+ "status": "Created",
+ "code": 201,
+ "_postman_previewlanguage": "json",
+ "header": [
+ {
+ "key": "date",
+ "value": "Fri, 27 Sep 2024 09:19:28 GMT"
+ },
+ {
+ "key": "content-type",
+ "value": "application/json"
+ },
+ {
+ "key": "content-length",
+ "value": "104"
+ },
+ {
+ "key": "x-envoy-upstream-service-time",
+ "value": "11407"
+ },
+ {
+ "key": "server",
+ "value": "envoy"
+ }
+ ],
+ "cookie": [],
+ "body": "{\n \"request_uri\": \"urn:ietf:params:oauth:request_uri:1392f0f8-3068-4afe-a48a-d368cdab18e0\",\n \"expires_in\": 60\n}"
+ }
+ ]
+ },
+ {
+ "name": "Step 2 - Get Authorize (Follow instructions from Visualize tab)",
+ "event": [
+ {
+ "listen": "test",
+ "script": {
+ "exec": [
+ "pm.test(\"Response status code is 302\", function () {",
+ " pm.response.to.have.status(302);",
+ "});",
+ "",
+ "pm.test(\"location is present\", function () {",
+ " pm.response.to.have.header(\"location\");",
+ "});",
+ "",
+ "const link = pm.response.headers.get('location')",
+ "",
+ "pm.visualizer.set(`",
+ "Open this link in browser to login and authorize consent: ",
+ "`,",
+ "{",
+ " link: link, ",
+ "})",
+ ""
+ ],
+ "type": "text/javascript",
+ "packages": {}
+ }
+ }
+ ],
+ "request": {
+ "method": "GET",
+ "header": [],
+ "url": {
+ "raw": "{{baseUrl}}/fdx/auth/v1/authorize?client_id={{clientId}}&request_uri={{request_uri}}",
+ "host": [
+ "{{baseUrl}}"
+ ],
+ "path": [
+ "fdx",
+ "auth",
+ "v1",
+ "authorize"
+ ],
+ "query": [
+ {
+ "key": "client_id",
+ "value": "{{clientId}}"
+ },
+ {
+ "key": "request_uri",
+ "value": "{{request_uri}}"
+ }
+ ]
+ },
+ "description": "- Once you get the response, go to Visualize tab and copy the available link. You need to use this link in the browser of your choice and complete login.\n \n- For login credentials, contact the financial instititution.\n \n- Complete the authorization by granting access to accounts.\n \n- Once redirects are done, copy the URL from the browser's address bar."
+ },
+ "response": [
+ {
+ "name": "Step 2 - Get Authorize (Follow instructions from Visualize tab)",
+ "originalRequest": {
+ "method": "GET",
+ "header": [],
+ "url": {
+ "raw": "{{baseUrl}}/fdx/auth/v1/authorize?client_id={{clientId}}&request_uri={{request_uri}}",
+ "host": [
+ "{{baseUrl}}"
+ ],
+ "path": [
+ "fdx",
+ "auth",
+ "v1",
+ "authorize"
+ ],
+ "query": [
+ {
+ "key": "client_id",
+ "value": "{{clientId}}"
+ },
+ {
+ "key": "request_uri",
+ "value": "{{request_uri}}"
+ }
+ ]
+ }
+ },
+ "status": "Found",
+ "code": 302,
+ "_postman_previewlanguage": "plain",
+ "header": [
+ {
+ "key": "date",
+ "value": "Fri, 27 Sep 2024 09:19:39 GMT"
+ },
+ {
+ "key": "content-type",
+ "value": "text/plain"
+ },
+ {
+ "key": "content-length",
+ "value": "2"
+ },
+ {
+ "key": "location",
+ "value": "https://auth.openbanking.axwaysbsdev.net/realms/griffin-live/protocol/openid-connect/auth?client_id=af20ad73-9ee5-42d4-a1fb-70bfd5de3fdf&request_uri=urn:ietf:params:oauth:request_uri:1392f0f8-3068-4afe-a48a-d368cdab18e0&resourceId=66f6789e31f11123c37dfbfe&resourceType=AIS&authorizationId=66f6789f31f11123c37dfc00"
+ },
+ {
+ "key": "x-envoy-upstream-service-time",
+ "value": "981"
+ },
+ {
+ "key": "server",
+ "value": "envoy"
+ }
+ ],
+ "cookie": [],
+ "body": "{}"
+ }
+ ]
+ },
+ {
+ "name": "Step 2.1 Get Code from Redirect URL (paste url in body)",
+ "event": [
+ {
+ "listen": "prerequest",
+ "script": {
+ "exec": [
+ "const url = pm.request.body.raw",
+ "",
+ "const queryString = url.split('?')[1];",
+ "",
+ "if (!queryString) {",
+ " console.warn(\"URL doesn't contain a query string\");",
+ " return;",
+ "}",
+ "",
+ "// Split the query string by separators (assumes '&' and '=')",
+ "const params = queryString.split('&').reduce((obj, param) => {",
+ " const [key, value] = param.split('=');",
+ " obj[key] = value;",
+ " return obj;",
+ "}, {});",
+ "",
+ "// Check for \"response\" parameter",
+ "const token = params.response;",
+ "",
+ "if (!token) {",
+ " console.warn(\"URL doesn't contain a 'response' query parameter with the JWT token\");",
+ "} else {",
+ " // Split the token into parts (header, payload, signature)",
+ " const parts = token.split('.');",
+ " if (parts.length !== 3) {",
+ " console.warn(\"Invalid JWT token format\");",
+ " } else {",
+ " // Decode the payload (base64 encoded)",
+ " const decodedPayload = atob(parts[1]); // atob is for base64 decoding",
+ "",
+ " try {",
+ " // Parse the decoded payload as JSON",
+ " const payload = JSON.parse(decodedPayload);",
+ "",
+ " // Extract the \"code\" claim",
+ " const code = payload.code;",
+ "",
+ " if (code) {",
+ " // Store the code in a variable for use in the request",
+ " pm.collectionVariables.set(\"code\", code);",
+ " console.log(\"Extracted code claim:\", code);",
+ " } else {",
+ " console.warn(\"JWT token doesn't contain a 'code' claim\");",
+ " }",
+ " } catch (error) {",
+ " console.warn(\"Error decoding JWT payload:\", error);",
+ " }",
+ " }",
+ "}"
+ ],
+ "type": "text/javascript",
+ "packages": {}
+ }
+ }
+ ],
+ "protocolProfileBehavior": {
+ "disableBodyPruning": true
+ },
+ "request": {
+ "method": "GET",
+ "header": [],
+ "body": {
+ "mode": "raw",
+ "raw": "https://oauth.pstmn.io/v1/callback?response=eyJhbGciOiJQUzI1NiIsInR5cCIgOiAiSldUIiwia2lkIiA6ICJtbkplLW1wbTRoX0puMTJRMzhOV0JaUU1xZHQzekhkS2N6ZWNkM0lKTl80In0.eyJleHAiOjE3MjIzNDgxNTUsImlzcyI6Imh0dHBzOi8vYXV0aC5vcGVuYmFua2luZy5heHdheXNic2Rldi5uZXQvcmVhbG1zL2dyaWZmaW4tbGl2ZSIsImF1ZCI6ImVtb25leSIsImNvZGUiOiI2M2Q4NWVlMy1hMTNkLTRjMWYtOTJhZi00NmViMDMwMTc1ZmEuYzA2MDc3NzAtMzE5Ni00NTg0LTljM2YtNWIxMDU2NDI1YjY1LjM1Njg2OTlhLTM1OTMtNGQ2Yy05YmI5LWVmMjg0N2I5MTVlNiIsImlzcyI6Imh0dHBzOi8vYXV0aC5vcGVuYmFua2luZy5heHdheXNic2Rldi5uZXQvcmVhbG1zL2dyaWZmaW4tbGl2ZSIsInN0YXRlIjoiNGE4NzQwNTAtZjgyNi00N2YyLTg1MjUtMWE0NThkMjE5ZmY4Iiwic2Vzc2lvbl9zdGF0ZSI6ImMwNjA3NzcwLTMxOTYtNDU4NC05YzNmLTViMTA1NjQyNWI2NSJ9.nX_cEVwxBCAekLvjCwnzYsNGRBEEX89IjFMs8Ur89sgMRff9vrJWIZ_H2fm8U2YaIjfdSGJGCTJwvZWE5Q9O6Oq0dkHQXsEf-M7FF7JTWhVaOpgUtJgj_7coBdOBb3mu-gygYoD02CtdCt1Rt1PalmAimjryGYqH543Xdgxp9MJ8i7EZPPiKVChE_4lyqmL-tNCWkvvtujQPRr15IoZamzSZ2799Vv-hJ3PydmZ6Hjw8pagPJ2k2sbZVur7gt2uCDJsHeD21AL9YML3YJ1_uvGWqrUGvYRscL31TVs3U69i1DNp5EJu9PXhn_N6YPyCN-zDFlY9GDdGXLV5hqN9Vzw",
+ "options": {
+ "raw": {
+ "language": "json"
+ }
+ }
+ },
+ "url": {
+ "raw": "https://postman-echo.com/get",
+ "protocol": "https",
+ "host": [
+ "postman-echo",
+ "com"
+ ],
+ "path": [
+ "get"
+ ]
+ },
+ "description": "Paste the URL copied in previous step in the body of the request. In the response you will get authorization code."
+ },
+ "response": [
+ {
+ "name": "Step 1a. Get Code from Redirect URL (paste url in body)",
+ "originalRequest": {
+ "method": "GET",
+ "header": [],
+ "body": {
+ "mode": "raw",
+ "raw": "https://oauth.pstmn.io/v1/callback?response=eyJhbGciOiJQUzI1NiIsInR5cCIgOiAiSldUIiwia2lkIiA6ICJtbkplLW1wbTRoX0puMTJRMzhOV0JaUU1xZHQzekhkS2N6ZWNkM0lKTl80In0.eyJleHAiOjE3MjIwMDgyMzQsImlzcyI6Imh0dHBzOi8vYXV0aC5vcGVuYmFua2luZy5heHdheXNic2Rldi5uZXQvcmVhbG1zL2dyaWZmaW4tbGl2ZSIsImF1ZCI6ImVtb25leSIsImNvZGUiOiJjNDhhM2M3YS00OTZmLTRhZDktYmJkYS0zOTBmYTUxNThhNjYuNTQ1ZjdmMTgtMzBlNi00MzE4LWI1YTYtYTBhZGYyZTk4OTZlLjM1Njg2OTlhLTM1OTMtNGQ2Yy05YmI5LWVmMjg0N2I5MTVlNiIsImlzcyI6Imh0dHBzOi8vYXV0aC5vcGVuYmFua2luZy5heHdheXNic2Rldi5uZXQvcmVhbG1zL2dyaWZmaW4tbGl2ZSIsInN0YXRlIjoiMTNjZDg0MGItN2JiNS00ZDEzLWI4NmItNmE2NGI3MmJjOGQ2Iiwic2Vzc2lvbl9zdGF0ZSI6IjU0NWY3ZjE4LTMwZTYtNDMxOC1iNWE2LWEwYWRmMmU5ODk2ZSJ9.obtnQibqbKTnrkOHrK1jbiqI6Hxb2gBn8_h2iGZWq9jnyvAzKQsGaSC0jvr1usQHhd1U-j8VLAagIzEAQxWLrrAG7AaZkgx4suKv-WqLp3DuiICTpk6-UuKwBrb3Pyu8Gq_o2R7sUxWMhI4M-NiezAvFLbkKOI7Y7X8Xjroq70Im8CcEuCt2EDou8zfa9u066c1h3-OP9CfUBAxFtiS9eqX4-u2opqLd3MfcrYZ7dAmVwmBM-qlys045yrEe3iunCEXkW_SfScsdZXRZ1tWAfn6VE2FMC5q5ftegsTqvUl3IUi6slZcaEkjLKd_Yux25-p9JShNgGIBO2eNEa5i2Pw",
+ "options": {
+ "raw": {
+ "language": "json"
+ }
+ }
+ },
+ "url": {
+ "raw": "https://postman-echo.com/get",
+ "protocol": "https",
+ "host": [
+ "postman-echo",
+ "com"
+ ],
+ "path": [
+ "get"
+ ]
+ }
+ },
+ "status": "OK",
+ "code": 200,
+ "_postman_previewlanguage": "json",
+ "header": [
+ {
+ "key": "Date",
+ "value": "Fri, 26 Jul 2024 15:32:32 GMT"
+ },
+ {
+ "key": "Content-Type",
+ "value": "application/json; charset=utf-8"
+ },
+ {
+ "key": "Content-Length",
+ "value": "627"
+ },
+ {
+ "key": "Connection",
+ "value": "close"
+ },
+ {
+ "key": "Server",
+ "value": "nginx/1.25.3"
+ },
+ {
+ "key": "ETag",
+ "value": "W/\"273-vVHifNsaeEGO8GI3W8qFyH0EPJE\""
+ },
+ {
+ "key": "set-cookie",
+ "value": "sails.sid=s%3A8lzMEOIe9_tTVDdha4UrgIl33Gl_LCdX.Kol%2FL9pIDL1%2BrmVgCn7%2FEKLSXnL4sfwotuLiQ9Q6edU; Path=/; HttpOnly"
+ }
+ ],
+ "cookie": [],
+ "body": "{\n \"args\": {},\n \"headers\": {\n \"host\": \"postman-echo.com\",\n \"x-request-start\": \"t=1722007952.456\",\n \"content-length\": \"6\",\n \"x-forwarded-proto\": \"https\",\n \"x-forwarded-port\": \"443\",\n \"x-amzn-trace-id\": \"Root=1-66a3c190-7b5081de7174600d46ca4846\",\n \"content-type\": \"application/json\",\n \"user-agent\": \"PostmanRuntime/7.40.0\",\n \"accept\": \"*/*\",\n \"postman-token\": \"0d3c895f-ac19-48c7-a297-1c15baf32aeb\",\n \"accept-encoding\": \"gzip, deflate, br\",\n \"cookie\": \"sails.sid=s%3AQbR8DmLDTlf6HhfpeIfrJL5a8t_lHW94.KSl2ZRDXNsKY57YwOnT3QoKoVWgtk1aoSzAAy52hZrE\"\n },\n \"url\": \"https://postman-echo.com/get\"\n}"
+ }
+ ]
+ },
+ {
+ "name": "Step 3 - Get Access Token",
+ "event": [
+ {
+ "listen": "test",
+ "script": {
+ "exec": [
+ "pm.test(\"Extract and store the access token, refresh token and consentId in collection variable\", function () {\r",
+ " const responseData = pm.response.json();\r",
+ " \r",
+ " pm.expect(responseData.refresh_token).to.exist;\r",
+ " pm.collectionVariables.set(\"access_token\", responseData.access_token);\r",
+ "\r",
+ " pm.expect(responseData.refresh_token).to.exist;\r",
+ " pm.collectionVariables.set(\"refresh_token\", responseData.refresh_token);\r",
+ "\r",
+ " pm.expect(responseData.refresh_token).to.exist;\r",
+ " pm.collectionVariables.set(\"consentId\", responseData.grant_id);\r",
+ "\r",
+ "});\r",
+ "\r",
+ "// Validate that the access_token, token_type, expires_in, refresh_token, scope, state, and grant_id fields are not null\r",
+ "pm.test(\"Access token is not null\", function () {\r",
+ " pm.expect(pm.response.json().access_token).to.not.be.null;\r",
+ "});\r",
+ "\r",
+ "pm.test(\"Token type is not null\", function () {\r",
+ " pm.expect(pm.response.json().token_type).to.not.be.null;\r",
+ "});\r",
+ "\r",
+ "pm.test(\"Expires in is not null\", function () {\r",
+ " pm.expect(pm.response.json().expires_in).to.not.be.null;\r",
+ "});\r",
+ "\r",
+ "pm.test(\"Refresh token is not null\", function () {\r",
+ " pm.expect(pm.response.json().refresh_token).to.not.be.null;\r",
+ "});\r",
+ "\r",
+ "pm.test(\"Scope is not null\", function () {\r",
+ " pm.expect(pm.response.json().scope).to.not.be.null;\r",
+ "});\r",
+ "\r",
+ "pm.test(\"State is not null\", function () {\r",
+ " pm.expect(pm.response.json().state).to.not.be.null;\r",
+ "});\r",
+ "\r",
+ "pm.test(\"Grant ID is not null\", function () {\r",
+ " pm.expect(pm.response.json().grant_id).to.not.be.null;\r",
+ "});\r",
+ ""
+ ],
+ "type": "text/javascript",
+ "packages": {}
+ }
+ },
+ {
+ "listen": "prerequest",
+ "script": {
+ "exec": [
+ ""
+ ],
+ "type": "text/javascript",
+ "packages": {}
+ }
+ }
+ ],
+ "request": {
+ "method": "POST",
+ "header": [
+ {
+ "key": "ssl-client-verify",
+ "value": "{{ssl-client-verify}}",
+ "type": "text"
+ },
+ {
+ "key": "ssl-client-cert",
+ "value": "{{ssl-client-cert}}",
+ "type": "text"
+ }
+ ],
+ "body": {
+ "mode": "urlencoded",
+ "urlencoded": [
+ {
+ "key": "redirect_uri",
+ "value": "https://oauth.pstmn.io/v1/callback",
+ "type": "text"
+ },
+ {
+ "key": "code",
+ "value": "{{code}}",
+ "type": "text"
+ },
+ {
+ "key": "client_id",
+ "value": "{{clientId}}",
+ "type": "text"
+ },
+ {
+ "key": "code_verifier",
+ "value": "{{code_verifier}}",
+ "type": "text"
+ },
+ {
+ "key": "grant_type",
+ "value": "authorization_code",
+ "type": "text"
+ }
+ ]
+ },
+ "url": {
+ "raw": "{{baseUrl}}/fdx/auth/v1/token",
+ "host": [
+ "{{baseUrl}}"
+ ],
+ "path": [
+ "fdx",
+ "auth",
+ "v1",
+ "token"
+ ]
+ },
+ "description": "### Endpoint Description\n\nThis endpoint is used to make an HTTP POST request to obtain a token for authentication. Once you gets the token in response you are ready to call rest of the API endpoints in this collection. No more copy paste required.\n\n### Request Body\n\n- The request body should be of type x-www-form-urlencoded.\n \n\n### Response\n\nThe response for this request is a JSON object with the following properties:\n\n- `access_token` (string): The access token obtained.\n \n- `expires_in` (number): The duration until the token expires.\n \n- `refresh_expires_in` (number): The duration until the refresh token expires.\n \n- `refresh_token` (string): The refresh token obtained.\n \n- `token_type` (string): The type of token obtained.\n \n- `not-before-policy` (number): Not-before policy value.\n \n- `session_state` (string): The session state.\n \n- `scope` (string): The scope of the token.\n \n- `grant_id` (string): The grant ID.\n \n\n### JSON Schema\n\n``` json\n{\n \"type\": \"object\",\n \"properties\": {\n \"access_token\": { \"type\": \"string\" },\n \"expires_in\": { \"type\": \"number\" },\n \"refresh_expires_in\": { \"type\": \"number\" },\n \"refresh_token\": { \"type\": \"string\" },\n \"token_type\": { \"type\": \"string\" },\n \"not-before-policy\": { \"type\": \"number\" },\n \"session_state\": { \"type\": \"string\" },\n \"scope\": { \"type\": \"string\" },\n \"grant_id\": { \"type\": \"string\" }\n }\n}\n\n ```"
+ },
+ "response": [
+ {
+ "name": "Step 3 - Get Access Token",
+ "originalRequest": {
+ "method": "POST",
+ "header": [
+ {
+ "key": "ssl-client-verify",
+ "value": "{{ssl-client-verify}}",
+ "type": "text"
+ },
+ {
+ "key": "ssl-client-cert",
+ "value": "{{ssl-client-cert}}",
+ "type": "text"
+ }
+ ],
+ "body": {
+ "mode": "urlencoded",
+ "urlencoded": [
+ {
+ "key": "redirect_uri",
+ "value": "https://oauth.pstmn.io/v1/callback",
+ "type": "text"
+ },
+ {
+ "key": "code",
+ "value": "{{code}}",
+ "type": "text"
+ },
+ {
+ "key": "client_id",
+ "value": "{{clientId}}",
+ "type": "text"
+ },
+ {
+ "key": "code_verifier",
+ "value": "{{code_verifier}}",
+ "type": "text"
+ },
+ {
+ "key": "grant_type",
+ "value": "authorization_code",
+ "type": "text"
+ }
+ ]
+ },
+ "url": {
+ "raw": "{{baseUrl}}/fdx/auth/v1/token",
+ "host": [
+ "{{baseUrl}}"
+ ],
+ "path": [
+ "fdx",
+ "auth",
+ "v1",
+ "token"
+ ]
+ }
+ },
+ "status": "OK",
+ "code": 200,
+ "_postman_previewlanguage": "json",
+ "header": [
+ {
+ "key": "date",
+ "value": "Fri, 27 Sep 2024 09:21:24 GMT"
+ },
+ {
+ "key": "content-type",
+ "value": "application/json"
+ },
+ {
+ "key": "content-length",
+ "value": "2716"
+ },
+ {
+ "key": "x-envoy-upstream-service-time",
+ "value": "2455"
+ },
+ {
+ "key": "server",
+ "value": "envoy"
+ }
+ ],
+ "cookie": [],
+ "body": "{\n \"access_token\": \"eyJhbGciOiJQUzI1NiIsInR5cCIgOiAiSldUIiwia2lkIiA6ICJCeWQ0UklSMXpMeUluZi10M1RMV1p1Ql91NUJYVUFVOXc4NEJCQ3duQXNJIn0.eyJleHAiOjE3Mjc0MjkxODIsImlhdCI6MTcyNzQyODg4MiwiYXV0aF90aW1lIjoxNzI3NDI4ODM1LCJqdGkiOiIzODMwNTE4NC0wZTIzLTQ3M2ItYWYxMi00ZTZiZmZkNjhmZWYiLCJpc3MiOiJodHRwczovL2dyaWZmaW4tbGl2ZS5vcGVuYmFua2luZy5heHdheXNic2Rldi5uZXQ6NDQ0My9mZHgvYXV0aC92MSIsInN1YiI6ImMzZjVmZTBmLWExNTMtNDZjOC1iZWFjLTZlNjE4NjgxNTllYSIsInR5cCI6IkJlYXJlciIsImF6cCI6ImFmMjBhZDczLTllZTUtNDJkNC1hMWZiLTcwYmZkNWRlM2ZkZiIsInNpZCI6IjI1NTFmM2YwLTY5ODUtNDMxZS05NjU4LWM2NTFlMzEzNGI5OCIsImNuZiI6eyJ4NXQjUzI1NiI6IldmaVplZFJSc2dWOWxHTmV3MjBkMk1sblYyT2NENFd6TmsxcGJBYkt1VlkifSwic2NvcGUiOiJmZHg6YWNjb3VudGJhc2ljOnJlYWQgZmR4OnBheW1lbnRzdXBwb3J0OnJlYWQgZmR4OmN1c3RvbWVyY29udGFjdDpyZWFkIGZkeDp0cmFuc2FjdGlvbnM6cmVhZCBmZHg6YWNjb3VudGRldGFpbGVkOnJlYWQiLCJ0ZW5hbnRJbmZvcm1hdGlvbiI6eyJ0ZW5hbnROYW1lIjoiZ3JpZmZpbiIsInRlbmFudElkIjoiUFMxMTA2MjAwMCJ9LCJmZHhDb25zZW50SWQiOiI2NmY2Nzg5ZTMxZjExMTIzYzM3ZGZiZmUifQ.SEgOqBQ7QJIWcfOODMp4dXak5Uw53vQQRsEM8AFGHA1r1T2xhAfBfsFtWMrbbX1EeE0pm9-MPXqMnOOeAC5eqDdDPo63iAaXuA-vP-2QVGB0Jfe1hnQmPXEIeU8iprPhikjFZ_7FxVuwtS4H-S0m8HPl9r-Z2gLMogJM5_zHr_lY5d7edAFjeIzrDsuaPfFDRYH9cm2sU-IRx34JXIBNjCegeRsVNO8tK9wzbodCOnq2KBf6yQXRkr02Sf8Rz0DV4B5yPm1bb8bL7Hj2axGpu9JQOwVfTwxXKz2X_UcZzI_jclhWztGbmmm5OgqrMVECxhtz2js_L8UTDQjTi0HMlg\",\n \"expires_in\": 300,\n \"refresh_expires_in\": 2592000,\n \"refresh_token\": \"eyJhbGciOiJIUzUxMiIsInR5cCIgOiAiSldUIiwia2lkIiA6ICIwNjMwMTBkYi03ZmQ0LTQ0YmUtYjJmYi0wZTFhMDYwMTI5NzYifQ.eyJleHAiOjE3MzAwMjA4ODIsImlhdCI6MTcyNzQyODg4MiwianRpIjoiOTJkOTZlODktNzdlOC00YTcxLTlmYzctNzE4OTlmMDFiNzcyIiwiaXNzIjoiaHR0cHM6Ly9ncmlmZmluLWxpdmUub3BlbmJhbmtpbmcuYXh3YXlzYnNkZXYubmV0OjQ0NDMvZmR4L2F1dGgvdjEiLCJhdWQiOiJodHRwczovL2dyaWZmaW4tbGl2ZS5vcGVuYmFua2luZy5heHdheXNic2Rldi5uZXQ6NDQ0My9mZHgvYXV0aC92MSIsInN1YiI6ImMzZjVmZTBmLWExNTMtNDZjOC1iZWFjLTZlNjE4NjgxNTllYSIsInR5cCI6IlJlZnJlc2giLCJhenAiOiJhZjIwYWQ3My05ZWU1LTQyZDQtYTFmYi03MGJmZDVkZTNmZGYiLCJzaWQiOiIyNTUxZjNmMC02OTg1LTQzMWUtOTY1OC1jNjUxZTMxMzRiOTgiLCJjbmYiOnsieDV0I1MyNTYiOiJXZmlaZWRSUnNnVjlsR05ldzIwZDJNbG5WMk9jRDRXek5rMXBiQWJLdVZZIn0sInNjb3BlIjoiZmR4LXJlc291cmNlIGZkeDphY2NvdW50YmFzaWM6cmVhZCB0ZW5hbnQtaW5mb3JtYXRpb24gZmR4OnBheW1lbnRzdXBwb3J0OnJlYWQgZmR4OmN1c3RvbWVyY29udGFjdDpyZWFkIGZkeDp0cmFuc2FjdGlvbnM6cmVhZCBmZHg6YWNjb3VudGRldGFpbGVkOnJlYWQgYmFzaWMiLCJyZXVzZV9pZCI6IjFhNmY3N2RmLTU3MzktNGRmNy04Mjg4LTk3OTllNzk3NDQ4ZCJ9.BeH2FKC_9nsRjTOyPyhDeVTU2_Pl2L1EPSIZrne43Xm8hhmm2CczXxIzIsAkabDMrHnDS-Tl85XKUeCqW2nb6w\",\n \"token_type\": \"Bearer\",\n \"not-before-policy\": 0,\n \"session_state\": \"2551f3f0-6985-431e-9658-c651e3134b98\",\n \"scope\": \"fdx:accountbasic:read fdx:paymentsupport:read fdx:customercontact:read fdx:transactions:read fdx:accountdetailed:read\",\n \"grant_id\": \"66f6789e31f11123c37dfbfe\"\n}"
+ }
+ ]
+ }
+ ],
+ "description": "Requests in this folder needs to be run first in overall collection and in the sequence as defined in the request names."
+ },
+ {
+ "name": "Accounts",
+ "item": [
+ {
+ "name": "Get Accounts",
+ "event": [
+ {
+ "listen": "test",
+ "script": {
+ "exec": [
+ "pm.test(\"Response status code is 200\", function () {",
+ " pm.response.to.have.status(200);",
+ "});",
+ "",
+ "",
+ "pm.test(\"Content-Type header is application/json\", function () {",
+ " pm.expect(pm.response.headers.get(\"Content-Type\")).to.include(\"application/json\");",
+ "});",
+ "",
+ "",
+ "pm.test(\"Validate the accounts array and its structure\", function () {",
+ " const responseData = pm.response.json();",
+ " ",
+ " pm.expect(responseData.accounts).to.be.an('array');",
+ " pm.expect(responseData.accounts).to.have.lengthOf.at.least(1, \"Accounts array should not be empty\");",
+ "",
+ "});"
+ ],
+ "type": "text/javascript",
+ "packages": {}
+ }
+ }
+ ],
+ "request": {
+ "method": "GET",
+ "header": [
+ {
+ "key": "x-fapi-interaction-id",
+ "value": "2398f777-9259-4e50-867e-27247a143b1f"
+ },
+ {
+ "key": "Authorization",
+ "value": "Bearer {{access_token}}",
+ "type": "text"
+ }
+ ],
+ "url": {
+ "raw": "{{baseUrl}}/fdx/v6/core/accounts",
+ "host": [
+ "{{baseUrl}}"
+ ],
+ "path": [
+ "fdx",
+ "v6",
+ "core",
+ "accounts"
+ ]
+ }
+ },
+ "response": [
+ {
+ "name": "Get Accounts",
+ "originalRequest": {
+ "method": "GET",
+ "header": [
+ {
+ "key": "x-fapi-interaction-id",
+ "value": "2398f777-9259-4e50-867e-27247a143b1f"
+ },
+ {
+ "key": "Authorization",
+ "value": "Bearer {{access_token}}",
+ "type": "text"
+ }
+ ],
+ "url": {
+ "raw": "{{baseUrl}}/fdx/v6/core/accounts",
+ "host": [
+ "{{baseUrl}}"
+ ],
+ "path": [
+ "fdx",
+ "v6",
+ "core",
+ "accounts"
+ ]
+ }
+ },
+ "status": "OK",
+ "code": 200,
+ "_postman_previewlanguage": "json",
+ "header": [
+ {
+ "key": "date",
+ "value": "Fri, 27 Sep 2024 09:21:45 GMT"
+ },
+ {
+ "key": "x-fapi-interaction-id",
+ "value": "2398f777-9259-4e50-867e-27247a143b1f"
+ },
+ {
+ "key": "content-type",
+ "value": "application/json"
+ },
+ {
+ "key": "content-length",
+ "value": "980"
+ },
+ {
+ "key": "x-envoy-upstream-service-time",
+ "value": "7458"
+ },
+ {
+ "key": "server",
+ "value": "envoy"
+ }
+ ],
+ "cookie": [],
+ "body": "{\n \"accounts\": [\n {\n \"accountCategory\": \"DEPOSIT_ACCOUNT\",\n \"accountId\": \"948759it3kbm5b3fdkj454\",\n \"accountType\": \"CHECKING\",\n \"accountNumber\": \"1028462538\",\n \"accountNumberDisplay\": \"******2538\",\n \"productName\": \"Checking account\",\n \"nickname\": \"My Checkings\",\n \"status\": \"OPEN\",\n \"description\": \"John Doe's checking account\",\n \"currency\": {\n \"currencyCode\": \"USD\"\n },\n \"fiAttributes\": [\n {\n \"name\": \"attribute1\",\n \"value\": \"12435456\"\n },\n {\n \"name\": \"attribute2\",\n \"value\": \"ABCDEF\"\n }\n ],\n \"parentAccountId\": \"91da8f01-40b2-5d38-1bfc-581fbf8eb169\"\n },\n {\n \"accountCategory\": \"DEPOSIT_ACCOUNT\",\n \"accountId\": \"948759it3kbm5b3f1234454\",\n \"accountType\": \"SAVINGS\",\n \"accountNumber\": \"7234234543\",\n \"accountNumberDisplay\": \"******4543\",\n \"productName\": \"Savings account\",\n \"nickname\": \"My Savings\",\n \"status\": \"OPEN\",\n \"description\": \"John Doe's saving account\",\n \"currency\": {\n \"currencyCode\": \"USD\"\n },\n \"fiAttributes\": [\n {\n \"name\": \"attribute1\",\n \"value\": \"12435456\"\n },\n {\n \"name\": \"attribute2\",\n \"value\": \"ABCDEF\"\n }\n ],\n \"parentAccountId\": \"91da8f01-40b2-5d38-1bfc-581fbf8eb169\"\n }\n ],\n \"page\": {\n \"totalElements\": 2\n }\n}"
+ }
+ ]
+ },
+ {
+ "name": "Get Account by Id",
+ "event": [
+ {
+ "listen": "test",
+ "script": {
+ "exec": [
+ "pm.test(\"Response status code is 200\", function () {",
+ " pm.response.to.have.status(200);",
+ "});",
+ "",
+ "",
+ "pm.test(\"Content-Type header is application/json\", function () {",
+ " pm.expect(pm.response.headers.get(\"Content-Type\")).to.include(\"application/json\");",
+ "});",
+ ""
+ ],
+ "type": "text/javascript",
+ "packages": {}
+ }
+ }
+ ],
+ "request": {
+ "method": "GET",
+ "header": [
+ {
+ "key": "x-fapi-interaction-id",
+ "value": "2398f777-9259-4e50-867e-27247a143b1f"
+ },
+ {
+ "key": "Authorization",
+ "value": "Bearer {{access_token}}",
+ "type": "text"
+ }
+ ],
+ "url": {
+ "raw": "{{baseUrl}}/fdx/v6/core/accounts/{{accountId}}",
+ "host": [
+ "{{baseUrl}}"
+ ],
+ "path": [
+ "fdx",
+ "v6",
+ "core",
+ "accounts",
+ "{{accountId}}"
+ ]
+ }
+ },
+ "response": [
+ {
+ "name": "Get Account by Id",
+ "originalRequest": {
+ "method": "GET",
+ "header": [
+ {
+ "key": "x-fapi-interaction-id",
+ "value": "2398f777-9259-4e50-867e-27247a143b1f"
+ },
+ {
+ "key": "Authorization",
+ "value": "Bearer {{access_token}}",
+ "type": "text"
+ }
+ ],
+ "url": {
+ "raw": "{{baseUrl}}/fdx/v6/core/accounts/{{accountId}}",
+ "host": [
+ "{{baseUrl}}"
+ ],
+ "path": [
+ "fdx",
+ "v6",
+ "core",
+ "accounts",
+ "{{accountId}}"
+ ]
+ }
+ },
+ "status": "OK",
+ "code": 200,
+ "_postman_previewlanguage": "json",
+ "header": [
+ {
+ "key": "date",
+ "value": "Fri, 27 Sep 2024 09:22:03 GMT"
+ },
+ {
+ "key": "x-fapi-interaction-id",
+ "value": "2398f777-9259-4e50-867e-27247a143b1f"
+ },
+ {
+ "key": "content-type",
+ "value": "application/json"
+ },
+ {
+ "key": "content-length",
+ "value": "1940"
+ },
+ {
+ "key": "x-envoy-upstream-service-time",
+ "value": "7458"
+ },
+ {
+ "key": "server",
+ "value": "envoy"
+ }
+ ],
+ "cookie": [],
+ "body": "{\n \"accountCategory\": \"DEPOSIT_ACCOUNT\",\n \"accountId\": \"948759it3kbm5b3fdkj454\",\n \"accountNumber\": \"1028462538\",\n \"accountNumberDisplay\": \"******2538\",\n \"accountOpenDate\": \"2021-07-15\",\n \"accountType\": \"CHECKING\",\n \"annualPercentageYield\": 0,\n \"availableBalance\": 2454.6,\n \"balanceAsOf\": \"2024-07-15T14:46:41.375Z\",\n \"balanceType\": \"ASSET\",\n \"billPayStatus\": \"ACTIVE\",\n \"currency\": {\n \"currencyCode\": \"USD\"\n },\n \"currentBalance\": 2454.6,\n \"description\": \"John Doe's checking account\",\n \"domicile\": {\n \"region\": \"NY\",\n \"country\": \"US\"\n },\n \"earlyPenaltyFlag\": true,\n \"fiAttributes\": [\n {\n \"name\": \"attribute1\",\n \"value\": \"12435456\"\n },\n {\n \"name\": \"attribute2\",\n \"value\": \"ABCDEF\"\n }\n ],\n \"interestRate\": 0,\n \"interestRateAsOf\": \"2021-07-15T14:46:41.375Z\",\n \"interestRateType\": \"FIXED\",\n \"interestYtd\": 0,\n \"lastActivityDate\": \"2024-07-15\",\n \"lineOfBusiness\": \"consumer\",\n \"maturityDate\": \"2021-07-15\",\n \"micrNumber\": \"12443240\",\n \"nickname\": \"My Checkings\",\n \"openingDayBalance\": 2454.6,\n \"parentAccountId\": \"91da8f01-40b2-5d38-1bfc-581fbf8eb169\",\n \"priorInterestRate\": 0,\n \"productName\": \"Checking account\",\n \"rewardProgramId\": \"10001\",\n \"routingTransitNumber\": \"00123000220\",\n \"status\": \"OPEN\",\n \"term\": 0,\n \"transactionsIncluded\": false,\n \"transferIn\": true,\n \"transferOut\": true,\n \"contact\": {\n \"addresses\": [\n {\n \"city\": \"New York\",\n \"country\": \"US\",\n \"line1\": \"829 Spring St.\",\n \"postalCode\": \"10040\",\n \"region\": \"NY\"\n }\n ],\n \"emails\": [\n \"johndoe@demo.com\"\n ],\n \"holders\": [\n {\n \"customerId\": \"49\",\n \"dateOfBirth\": \"2002-08-21\",\n \"governmentId\": \"BBshg054Thv\",\n \"relationship\": \"PRIMARY\",\n \"type\": \"CONSUMER\",\n \"emails\": [\n \"john.doe@gmailcom\",\n \"jd@gmail.com\"\n ],\n \"telephones\": [\n {\n \"type\": \"HOME\",\n \"country\": \"US\",\n \"number\": \"8756565565\"\n }\n ],\n \"name\": {\n \"first\": \"John\",\n \"middle\": \"middle\",\n \"last\": \"Doe\",\n \"suffix\": \"suffix\",\n \"prefix\": \"Mr\",\n \"company\": \"Abc Tech company\"\n },\n \"addresses\": [\n {\n \"line1\": \"#85\",\n \"line2\": \"lastangel\",\n \"line3\": \"Carron\",\n \"city\": \"swiz\",\n \"state\": \"Cargo\",\n \"region\": \"region\",\n \"postalCode\": \"88556\",\n \"country\": \"US\",\n \"type\": \"MAILING\"\n }\n ]\n }\n ],\n \"telephones\": [\n {\n \"type\": \"CELL\",\n \"country\": \"1\",\n \"number\": \"212-916-5097\"\n },\n {\n \"type\": \"HOME\",\n \"country\": \"1\",\n \"number\": \"845-670-0862\"\n }\n ]\n }\n}"
+ }
+ ]
+ },
+ {
+ "name": "Get Account Transactions",
+ "event": [
+ {
+ "listen": "test",
+ "script": {
+ "exec": [
+ "pm.test(\"Response status code is 200\", function () {",
+ " pm.response.to.have.status(200);",
+ "});",
+ "",
+ "",
+ "pm.test(\"Content-Type header is application/json\", function () {",
+ " pm.expect(pm.response.headers.get(\"Content-Type\")).to.include(\"application/json\");",
+ "});"
+ ],
+ "type": "text/javascript",
+ "packages": {}
+ }
+ }
+ ],
+ "request": {
+ "method": "GET",
+ "header": [
+ {
+ "key": "x-fapi-interaction-id",
+ "value": "2398f777-9259-4e50-867e-27247a143b1f"
+ },
+ {
+ "key": "Authorization",
+ "value": "Bearer {{access_token}}",
+ "type": "text"
+ }
+ ],
+ "url": {
+ "raw": "{{baseUrl}}/fdx/v6/core/accounts/{{accountId}}/transactions?startTime=2024-06-15&endTime=2024-07-26&limit=5&offset=Page1",
+ "host": [
+ "{{baseUrl}}"
+ ],
+ "path": [
+ "fdx",
+ "v6",
+ "core",
+ "accounts",
+ "{{accountId}}",
+ "transactions"
+ ],
+ "query": [
+ {
+ "key": "startTime",
+ "value": "2024-06-15"
+ },
+ {
+ "key": "endTime",
+ "value": "2024-07-26"
+ },
+ {
+ "key": "limit",
+ "value": "5"
+ },
+ {
+ "key": "offset",
+ "value": "Page1"
+ }
+ ]
+ }
+ },
+ "response": [
+ {
+ "name": "Get Account Transactions",
+ "originalRequest": {
+ "method": "GET",
+ "header": [
+ {
+ "key": "x-fapi-interaction-id",
+ "value": "2398f777-9259-4e50-867e-27247a143b1f"
+ },
+ {
+ "key": "Authorization",
+ "value": "Bearer {{access_token}}",
+ "type": "text"
+ }
+ ],
+ "url": {
+ "raw": "{{baseUrl}}/fdx/v6/core/accounts/{{accountId}}/transactions?startTime=2024-06-15&endTime=2024-07-26&limit=5&offset=Page1",
+ "host": [
+ "{{baseUrl}}"
+ ],
+ "path": [
+ "fdx",
+ "v6",
+ "core",
+ "accounts",
+ "{{accountId}}",
+ "transactions"
+ ],
+ "query": [
+ {
+ "key": "startTime",
+ "value": "2024-06-15"
+ },
+ {
+ "key": "endTime",
+ "value": "2024-07-26"
+ },
+ {
+ "key": "limit",
+ "value": "5"
+ },
+ {
+ "key": "offset",
+ "value": "Page1"
+ }
+ ]
+ }
+ },
+ "status": "OK",
+ "code": 200,
+ "_postman_previewlanguage": "json",
+ "header": [
+ {
+ "key": "date",
+ "value": "Fri, 27 Sep 2024 09:23:09 GMT"
+ },
+ {
+ "key": "x-fapi-interaction-id",
+ "value": "2398f777-9259-4e50-867e-27247a143b1f"
+ },
+ {
+ "key": "content-type",
+ "value": "application/json"
+ },
+ {
+ "key": "content-length",
+ "value": "2855"
+ },
+ {
+ "key": "x-envoy-upstream-service-time",
+ "value": "26960"
+ },
+ {
+ "key": "server",
+ "value": "envoy"
+ }
+ ],
+ "cookie": [],
+ "body": "{\n \"page\": {\n \"totalElements\": 18,\n \"nextOffset\": \"Page2\"\n },\n \"transactions\": [\n {\n \"accountId\": \"948759it3kbm5b3fdkj454\",\n \"accountCategory\": \"DEPOSIT_ACCOUNT\",\n \"transactionId\": \"T98224315404\",\n \"referenceTransactionId\": \"RT73659438576\",\n \"postedTimestamp\": \"2024-04-15T12:29:06Z\",\n \"transactionTimestamp\": \"2024-06-23T23:34:51Z\",\n \"description\": \"Online groceries\",\n \"memo\": \"note66\",\n \"debitCreditMemo\": \"DEBIT\",\n \"category\": \"SIC\",\n \"subCategory\": \"Online shopping\",\n \"reference\": \"R68078870179\",\n \"status\": \"AUTHORIZATION\",\n \"amount\": 1491.973856687403,\n \"transactionType\": \"ADJUSTMENT\",\n \"payee\": \"payee66\",\n \"checkNumber\": 77788572142\n },\n {\n \"accountId\": \"948759it3kbm5b3fdkj454\",\n \"accountCategory\": \"DEPOSIT_ACCOUNT\",\n \"transactionId\": \"T40278332806\",\n \"referenceTransactionId\": \"RT30767023464\",\n \"postedTimestamp\": \"2024-03-26T04:21:09Z\",\n \"transactionTimestamp\": \"2024-06-27T13:44:33Z\",\n \"description\": \"Clothing order\",\n \"memo\": \"note26\",\n \"debitCreditMemo\": \"CREDIT\",\n \"category\": \"SIC\",\n \"subCategory\": \"Online shopping\",\n \"reference\": \"R12399236734\",\n \"status\": \"AUTHORIZATION\",\n \"amount\": 427.936701109344,\n \"transactionType\": \"ADJUSTMENT\",\n \"payee\": \"payee26\",\n \"checkNumber\": 77788572102\n },\n {\n \"accountId\": \"948759it3kbm5b3fdkj454\",\n \"accountCategory\": \"DEPOSIT_ACCOUNT\",\n \"transactionId\": \"T43072721806\",\n \"referenceTransactionId\": \"RT28961399291\",\n \"postedTimestamp\": \"2024-06-18T13:38:01Z\",\n \"transactionTimestamp\": \"2024-06-29T04:35:56Z\",\n \"description\": \"Purchased electronics\",\n \"memo\": \"note73\",\n \"debitCreditMemo\": \"DEBIT\",\n \"category\": \"SIC\",\n \"subCategory\": \"Online shopping\",\n \"reference\": \"R70438758597\",\n \"status\": \"AUTHORIZATION\",\n \"amount\": 4162.789132059199,\n \"transactionType\": \"ADJUSTMENT\",\n \"payee\": \"payee73\",\n \"checkNumber\": 77788572149\n },\n {\n \"accountId\": \"948759it3kbm5b3fdkj454\",\n \"accountCategory\": \"DEPOSIT_ACCOUNT\",\n \"transactionId\": \"T99825723577\",\n \"referenceTransactionId\": \"RT85037387918\",\n \"postedTimestamp\": \"2024-09-03T16:48:44Z\",\n \"transactionTimestamp\": \"2024-06-30T21:54:10Z\",\n \"description\": \"Exchanged USD to EUR\",\n \"memo\": \"note72\",\n \"debitCreditMemo\": \"DEBIT\",\n \"category\": \"FX\",\n \"subCategory\": \"Currency Exchange\",\n \"reference\": \"R36526486814\",\n \"status\": \"AUTHORIZATION\",\n \"amount\": 1496.9398666283626,\n \"transactionType\": \"ADJUSTMENT\",\n \"payee\": \"payee72\",\n \"checkNumber\": 77788572148\n },\n {\n \"accountId\": \"948759it3kbm5b3fdkj454\",\n \"accountCategory\": \"DEPOSIT_ACCOUNT\",\n \"transactionId\": \"T59726955289\",\n \"referenceTransactionId\": \"RT17730688466\",\n \"postedTimestamp\": \"2024-01-13T10:33:03Z\",\n \"transactionTimestamp\": \"2024-07-06T22:51:28Z\",\n \"description\": \"Account to account\",\n \"memo\": \"note16\",\n \"debitCreditMemo\": \"DEBIT\",\n \"category\": \"Wire Transfer\",\n \"subCategory\": \"Domestic Transfer\",\n \"reference\": \"R91726241282\",\n \"status\": \"AUTHORIZATION\",\n \"amount\": 1874.3499017522554,\n \"transactionType\": \"ADJUSTMENT\",\n \"payee\": \"payee16\",\n \"checkNumber\": 77788572092\n }\n ],\n \"links\": {\n \"next\": {\n \"action\": \"GET\",\n \"rel\": \"next\",\n \"types\": [\n \"application/json\"\n ],\n \"href\": \"/fdx/v6/core/accounts/948759it3kbm5b3fdkj454/transactions?offset=Page2&startTime=2024-06-15&endTime=2024-07-26&limit=5\"\n }\n }\n}"
+ }
+ ]
+ },
+ {
+ "name": "Get Account's Contact Information",
+ "event": [
+ {
+ "listen": "test",
+ "script": {
+ "exec": [
+ "pm.test(\"Response status code is 200\", function () {",
+ " pm.response.to.have.status(200);",
+ "});",
+ "",
+ "",
+ "pm.test(\"Content-Type header is application/json\", function () {",
+ " pm.expect(pm.response.headers.get(\"Content-Type\")).to.include(\"application/json\");",
+ "});",
+ ""
+ ],
+ "type": "text/javascript",
+ "packages": {}
+ }
+ }
+ ],
+ "request": {
+ "method": "GET",
+ "header": [
+ {
+ "key": "x-fapi-interaction-id",
+ "value": "2398f777-9259-4e50-867e-27247a143b1f"
+ },
+ {
+ "key": "Authorization",
+ "value": "Bearer {{access_token}}",
+ "type": "text"
+ }
+ ],
+ "url": {
+ "raw": "{{baseUrl}}/fdx/v6/core/accounts/{{accountId}}/contact",
+ "host": [
+ "{{baseUrl}}"
+ ],
+ "path": [
+ "fdx",
+ "v6",
+ "core",
+ "accounts",
+ "{{accountId}}",
+ "contact"
+ ]
+ }
+ },
+ "response": [
+ {
+ "name": "Get Account's Contact Information",
+ "originalRequest": {
+ "method": "GET",
+ "header": [
+ {
+ "key": "x-fapi-interaction-id",
+ "value": "2398f777-9259-4e50-867e-27247a143b1f"
+ },
+ {
+ "key": "Authorization",
+ "value": "Bearer {{access_token}}",
+ "type": "text"
+ }
+ ],
+ "url": {
+ "raw": "{{baseUrl}}/fdx/v6/core/accounts/{{accountId}}/contact",
+ "host": [
+ "{{baseUrl}}"
+ ],
+ "path": [
+ "fdx",
+ "v6",
+ "core",
+ "accounts",
+ "{{accountId}}",
+ "contact"
+ ]
+ }
+ },
+ "status": "OK",
+ "code": 200,
+ "_postman_previewlanguage": "json",
+ "header": [
+ {
+ "key": "date",
+ "value": "Fri, 27 Sep 2024 09:53:57 GMT"
+ },
+ {
+ "key": "x-fapi-interaction-id",
+ "value": "2398f777-9259-4e50-867e-27247a143b1f"
+ },
+ {
+ "key": "content-type",
+ "value": "application/json"
+ },
+ {
+ "key": "content-length",
+ "value": "808"
+ },
+ {
+ "key": "x-envoy-upstream-service-time",
+ "value": "7410"
+ },
+ {
+ "key": "server",
+ "value": "envoy"
+ }
+ ],
+ "cookie": [],
+ "body": "{\n \"holders\": [\n {\n \"relationship\": \"PRIMARY\",\n \"type\": \"CONSUMER\",\n \"customerId\": \"49\",\n \"dateOfBirth\": \"2002-08-21\",\n \"taxId\": \"taxId\",\n \"governmentId\": \"BBshg054Thv\",\n \"name\": {\n \"first\": \"John\",\n \"middle\": \"middle\",\n \"last\": \"Doe\",\n \"suffix\": \"suffix\",\n \"prefix\": \"Mr\",\n \"company\": \"Abc Tech company\"\n },\n \"emails\": [\n \"john.doe@gmailcom\",\n \"jd@gmail.com\"\n ],\n \"addresses\": [\n {\n \"line1\": \"#85\",\n \"line2\": \"lastangel\",\n \"line3\": \"Carron\",\n \"city\": \"swiz\",\n \"state\": \"Cargo\",\n \"region\": \"region\",\n \"postalCode\": \"88556\",\n \"country\": \"US\",\n \"type\": \"MAILING\"\n }\n ],\n \"telephones\": [\n {\n \"type\": \"HOME\",\n \"country\": \"US\",\n \"number\": \"8756565565\"\n }\n ]\n }\n ],\n \"emails\": [\n \"johndoe@demo.com\"\n ],\n \"addresses\": [\n {\n \"line1\": \"829 Spring St.\",\n \"city\": \"New York\",\n \"region\": \"NY\",\n \"postalCode\": \"10040\",\n \"country\": \"US\"\n }\n ],\n \"telephones\": [\n {\n \"type\": \"CELL\",\n \"country\": \"1\",\n \"number\": \"212-916-5097\"\n },\n {\n \"type\": \"HOME\",\n \"country\": \"1\",\n \"number\": \"845-670-0862\"\n }\n ]\n}"
+ }
+ ]
+ },
+ {
+ "name": "Get Asset Transfer Details of Account",
+ "event": [
+ {
+ "listen": "test",
+ "script": {
+ "exec": [
+ "pm.test(\"Response status code is 200\", function () {",
+ " pm.response.to.have.status(200);",
+ "});",
+ "",
+ "",
+ "pm.test(\"Content-Type header is application/json\", function () {",
+ " pm.expect(pm.response.headers.get(\"Content-Type\")).to.include(\"application/json\");",
+ "});"
+ ],
+ "type": "text/javascript",
+ "packages": {}
+ }
+ }
+ ],
+ "request": {
+ "method": "GET",
+ "header": [
+ {
+ "key": "x-fapi-interaction-id",
+ "value": "2398f777-9259-4e50-867e-27247a143b1f"
+ },
+ {
+ "key": "Authorization",
+ "value": "Bearer {{access_token}}",
+ "type": "text"
+ }
+ ],
+ "url": {
+ "raw": "{{baseUrl}}/fdx/v6/core/accounts/{{accountId}}/asset-transfer-networks",
+ "host": [
+ "{{baseUrl}}"
+ ],
+ "path": [
+ "fdx",
+ "v6",
+ "core",
+ "accounts",
+ "{{accountId}}",
+ "asset-transfer-networks"
+ ]
+ }
+ },
+ "response": [
+ {
+ "name": "Get Asset Transfer Details of Account",
+ "originalRequest": {
+ "method": "GET",
+ "header": [
+ {
+ "key": "x-fapi-interaction-id",
+ "value": "2398f777-9259-4e50-867e-27247a143b1f"
+ },
+ {
+ "key": "Authorization",
+ "value": "Bearer {{access_token}}",
+ "type": "text"
+ }
+ ],
+ "url": {
+ "raw": "{{baseUrl}}/fdx/v6/core/accounts/{{accountId}}/asset-transfer-networks",
+ "host": [
+ "{{baseUrl}}"
+ ],
+ "path": [
+ "fdx",
+ "v6",
+ "core",
+ "accounts",
+ "{{accountId}}",
+ "asset-transfer-networks"
+ ]
+ }
+ },
+ "status": "OK",
+ "code": 200,
+ "_postman_previewlanguage": "json",
+ "header": [
+ {
+ "key": "date",
+ "value": "Fri, 27 Sep 2024 09:54:08 GMT"
+ },
+ {
+ "key": "x-fapi-interaction-id",
+ "value": "2398f777-9259-4e50-867e-27247a143b1f"
+ },
+ {
+ "key": "content-type",
+ "value": "application/json"
+ },
+ {
+ "key": "content-length",
+ "value": "518"
+ },
+ {
+ "key": "x-envoy-upstream-service-time",
+ "value": "7078"
+ },
+ {
+ "key": "server",
+ "value": "envoy"
+ }
+ ],
+ "cookie": [],
+ "body": "{\n \"assetTransferNetworks\": [\n {\n \"type\": \"US_ACATS\",\n \"identifier\": \"121000358\",\n \"identifierType\": \"ACCOUNT_NUMBER\",\n \"jointAccount\": true,\n \"institutionId\": \"1234567890\",\n \"institutionName\": \"US Investments\"\n },\n {\n \"type\": \"CA_ATON\",\n \"identifier\": \"TKN-221000360\",\n \"jointAccount\": true,\n \"institutionId\": \"1234567890\",\n \"identifierType\": \"TOKENIZED_ACCOUNT_NUMBER\",\n \"institutionName\": \"CANADA BANK\"\n },\n {\n \"type\": \"US_DTC\",\n \"identifier\": \"621000357\",\n \"jointAccount\": false,\n \"institutionId\": \"1234567890\",\n \"identifierType\": \"ACCOUNT_NUMBER\",\n \"institutionName\": \"US Bank\"\n }\n ]\n}"
+ }
+ ]
+ },
+ {
+ "name": "Get Payment Networks of Account",
+ "event": [
+ {
+ "listen": "test",
+ "script": {
+ "exec": [
+ "pm.test(\"Response status code is 200\", function () {",
+ " pm.response.to.have.status(200);",
+ "});",
+ "",
+ "",
+ "pm.test(\"Content-Type header is application/json\", function () {",
+ " pm.expect(pm.response.headers.get(\"Content-Type\")).to.include(\"application/json\");",
+ "});"
+ ],
+ "type": "text/javascript",
+ "packages": {}
+ }
+ }
+ ],
+ "request": {
+ "method": "GET",
+ "header": [
+ {
+ "key": "x-fapi-interaction-id",
+ "value": "2398f777-9259-4e50-867e-27247a143b1f"
+ },
+ {
+ "key": "Authorization",
+ "value": "Bearer {{access_token}}",
+ "type": "text"
+ }
+ ],
+ "url": {
+ "raw": "{{baseUrl}}/fdx/v6/core/accounts/{{accountId}}/payment-networks",
+ "host": [
+ "{{baseUrl}}"
+ ],
+ "path": [
+ "fdx",
+ "v6",
+ "core",
+ "accounts",
+ "{{accountId}}",
+ "payment-networks"
+ ]
+ }
+ },
+ "response": [
+ {
+ "name": "Get Payment Networks of Account",
+ "originalRequest": {
+ "method": "GET",
+ "header": [
+ {
+ "key": "x-fapi-interaction-id",
+ "value": "2398f777-9259-4e50-867e-27247a143b1f"
+ },
+ {
+ "key": "Authorization",
+ "value": "Bearer {{access_token}}",
+ "type": "text"
+ }
+ ],
+ "url": {
+ "raw": "{{baseUrl}}/fdx/v6/core/accounts/{{accountId}}/payment-networks",
+ "host": [
+ "{{baseUrl}}"
+ ],
+ "path": [
+ "fdx",
+ "v6",
+ "core",
+ "accounts",
+ "{{accountId}}",
+ "payment-networks"
+ ]
+ }
+ },
+ "status": "OK",
+ "code": 200,
+ "_postman_previewlanguage": "json",
+ "header": [
+ {
+ "key": "date",
+ "value": "Fri, 27 Sep 2024 09:54:44 GMT"
+ },
+ {
+ "key": "x-fapi-interaction-id",
+ "value": "2398f777-9259-4e50-867e-27247a143b1f"
+ },
+ {
+ "key": "content-type",
+ "value": "application/json"
+ },
+ {
+ "key": "content-length",
+ "value": "1569"
+ },
+ {
+ "key": "x-envoy-upstream-service-time",
+ "value": "8098"
+ },
+ {
+ "key": "server",
+ "value": "envoy"
+ }
+ ],
+ "cookie": [],
+ "body": "{\n \"page\": {\n \"totalElements\": 13,\n \"nextOffset\": \"Page2\"\n },\n \"paymentNetworks\": [\n {\n \"bankId\": \"501010\",\n \"identifier\": \"idd00test\",\n \"identifierType\": \"ACCOUNT_NUMBER\",\n \"type\": \"US_FEDWIRE\",\n \"transferIn\": true,\n \"transferOut\": true\n },\n {\n \"bankId\": \"501011\",\n \"identifier\": \"idd01test\",\n \"identifierType\": \"ACCOUNT_NUMBER\",\n \"type\": \"US_FEDWIRE\",\n \"transferIn\": true,\n \"transferOut\": true\n },\n {\n \"bankId\": \"501012\",\n \"identifier\": \"idd02test\",\n \"identifierType\": \"ACCOUNT_NUMBER\",\n \"type\": \"US_FEDWIRE\",\n \"transferIn\": true,\n \"transferOut\": true\n },\n {\n \"bankId\": \"501013\",\n \"identifier\": \"idd03test\",\n \"identifierType\": \"ACCOUNT_NUMBER\",\n \"type\": \"US_FEDWIRE\",\n \"transferIn\": true,\n \"transferOut\": true\n },\n {\n \"bankId\": \"501014\",\n \"identifier\": \"idd04test\",\n \"identifierType\": \"ACCOUNT_NUMBER\",\n \"type\": \"US_FEDWIRE\",\n \"transferIn\": true,\n \"transferOut\": true\n },\n {\n \"bankId\": \"501015\",\n \"identifier\": \"idd05test\",\n \"identifierType\": \"ACCOUNT_NUMBER\",\n \"type\": \"US_FEDWIRE\",\n \"transferIn\": true,\n \"transferOut\": true\n },\n {\n \"bankId\": \"501016\",\n \"identifier\": \"idd05test\",\n \"identifierType\": \"ACCOUNT_NUMBER\",\n \"type\": \"US_FEDWIRE\",\n \"transferIn\": true,\n \"transferOut\": true\n },\n {\n \"bankId\": \"501017\",\n \"identifier\": \"idd05test\",\n \"identifierType\": \"ACCOUNT_NUMBER\",\n \"type\": \"US_FEDWIRE\",\n \"transferIn\": true,\n \"transferOut\": true\n },\n {\n \"bankId\": \"501018\",\n \"identifier\": \"idd05test\",\n \"identifierType\": \"ACCOUNT_NUMBER\",\n \"type\": \"US_FEDWIRE\",\n \"transferIn\": true,\n \"transferOut\": true\n },\n {\n \"bankId\": \"501019\",\n \"identifier\": \"idd05test\",\n \"identifierType\": \"ACCOUNT_NUMBER\",\n \"type\": \"US_FEDWIRE\",\n \"transferIn\": true,\n \"transferOut\": true\n }\n ],\n \"links\": {\n \"next\": {\n \"href\": \"/948759it3kbm5b3fdkj454/payment-networks?offset=Page2\",\n \"action\": \"GET\",\n \"rel\": \"next\",\n \"types\": [\n \"application/json\"\n ]\n }\n }\n}"
+ }
+ ]
+ }
+ ]
+ },
+ {
+ "name": "Consent",
+ "item": [
+ {
+ "name": "Get Consent by id",
+ "event": [
+ {
+ "listen": "test",
+ "script": {
+ "exec": [
+ "pm.test(\"Response status code is 200\", function () {",
+ " pm.response.to.have.status(200);",
+ "});",
+ "",
+ "",
+ "pm.test(\"Content-Type header is application/json\", function () {",
+ " pm.expect(pm.response.headers.get(\"Content-Type\")).to.include(\"application/json\");",
+ "});",
+ "",
+ "",
+ "pm.test(\"Response has the required fields\", function () {",
+ " const responseData = pm.response.json();",
+ " ",
+ " pm.expect(responseData).to.be.an('object');",
+ " pm.expect(responseData).to.have.property('durationPeriod');",
+ " pm.expect(responseData).to.have.property('id');",
+ " pm.expect(responseData).to.have.property('expirationTime');",
+ " pm.expect(responseData).to.have.property('createdTime');",
+ " pm.expect(responseData).to.have.property('status');",
+ " pm.expect(responseData).to.have.property('resources');",
+ " pm.expect(responseData).to.have.property('durationType');",
+ "});",
+ "",
+ "",
+ "pm.test(\"Validate the resources array and its structure\", function () {",
+ " const responseData = pm.response.json();",
+ " ",
+ " pm.expect(responseData.resources).to.be.an('array');",
+ " pm.expect(responseData.resources).to.have.lengthOf.at.least(1, \"Resources array should not be empty\");",
+ "",
+ " responseData.resources.forEach(function(resource) {",
+ " pm.expect(resource).to.be.an('object');",
+ " // Add more specific checks for the structure of each resource if needed",
+ " });",
+ "});",
+ "",
+ "",
+ "pm.test(\"Expiration and created time are in valid date format\", function () {",
+ " const responseData = pm.response.json();",
+ " ",
+ " pm.expect(responseData.expirationTime).to.match(/^\\d{4}-\\d{2}-\\d{2}T\\d{2}:\\d{2}:\\d{2}Z$/, \"Expiration time should be in valid date format\");",
+ " pm.expect(responseData.createdTime).to.match(/^\\d{4}-\\d{2}-\\d{2}T\\d{2}:\\d{2}:\\d{2}Z$/, \"Created time should be in valid date format\");",
+ "});",
+ "pm.test(\"Id field is a valid UUID\", function () {",
+ " const responseData = pm.response.json();",
+ " const uuidRegex = /^[0-9a-f]{24}$/;",
+ " pm.expect(responseData.id).to.match(uuidRegex, \"Id should be a valid UUID\");",
+ "});"
+ ],
+ "type": "text/javascript",
+ "packages": {}
+ }
+ }
+ ],
+ "request": {
+ "method": "GET",
+ "header": [
+ {
+ "key": "x-fapi-interaction-id",
+ "value": "2398f777-9259-4e50-867e-27247a143b1f"
+ },
+ {
+ "key": "Authorization",
+ "value": "Bearer {{access_token}}",
+ "type": "text"
+ }
+ ],
+ "url": {
+ "raw": "{{baseUrl}}/fdx/v6/consents/{{consentId}}",
+ "host": [
+ "{{baseUrl}}"
+ ],
+ "path": [
+ "fdx",
+ "v6",
+ "consents",
+ "{{consentId}}"
+ ]
+ }
+ },
+ "response": [
+ {
+ "name": "Get Consent by id",
+ "originalRequest": {
+ "method": "GET",
+ "header": [
+ {
+ "key": "x-fapi-interaction-id",
+ "value": "2398f777-9259-4e50-867e-27247a143b1f"
+ },
+ {
+ "key": "Authorization",
+ "value": "Bearer {{access_token}}",
+ "type": "text"
+ }
+ ],
+ "url": {
+ "raw": "{{apiBaseUrl}}/fdx/v6/consents/{{consentId}}",
+ "host": [
+ "{{apiBaseUrl}}"
+ ],
+ "path": [
+ "fdx",
+ "v6",
+ "consents",
+ "{{consentId}}"
+ ]
+ }
+ },
+ "status": "OK",
+ "code": 200,
+ "_postman_previewlanguage": "json",
+ "header": [
+ {
+ "key": "Date",
+ "value": "Wed, 10 Jul 2024 11:59:51 GMT"
+ },
+ {
+ "key": "Content-type",
+ "value": "application/json"
+ },
+ {
+ "key": "Content-length",
+ "value": "777"
+ }
+ ],
+ "cookie": [],
+ "body": "{\n \"durationType\": \"TIME_BOUND\",\n \"id\": \"668e73b5c9adbc2db67f004f\",\n \"createdTime\": \"2024-07-10T11:42:45Z\",\n \"expirationTime\": \"2024-10-08T11:42:28Z\",\n \"updatedTime\": \"2024-07-10T11:46:08Z\",\n \"lookbackPeriod\": 60,\n \"durationPeriod\": 90,\n \"status\": \"REVOKED\",\n \"resources\": [\n {\n \"resourceId\": \"948759it3kbm5b3fdkj454\",\n \"dataClusters\": [\n \"ACCOUNT_BASIC\",\n \"ACCOUNT_DETAILED\",\n \"TRANSACTIONS\"\n ],\n \"resourceType\": \"ACCOUNT\"\n },\n {\n \"resourceId\": \"948759it3kbm5b3f1234454\",\n \"dataClusters\": [\n \"ACCOUNT_BASIC\",\n \"ACCOUNT_DETAILED\",\n \"TRANSACTIONS\"\n ],\n \"resourceType\": \"ACCOUNT\"\n },\n {\n \"resourceId\": \"7493c12151c4bb04e27caa\",\n \"dataClusters\": [\n \"ACCOUNT_BASIC\",\n \"ACCOUNT_DETAILED\",\n \"TRANSACTIONS\"\n ],\n \"resourceType\": \"ACCOUNT\"\n },\n {\n \"resourceId\": \"abc669672cb0869d382920\",\n \"dataClusters\": [\n \"ACCOUNT_BASIC\",\n \"ACCOUNT_DETAILED\",\n \"TRANSACTIONS\"\n ],\n \"resourceType\": \"ACCOUNT\"\n }\n ]\n}"
+ }
+ ]
+ },
+ {
+ "name": "Revoke Consent",
+ "event": [
+ {
+ "listen": "test",
+ "script": {
+ "exec": [
+ "pm.test(\"Response status code is 204\", function () {\r",
+ " pm.response.to.have.status(204);\r",
+ "});\r",
+ ""
+ ],
+ "type": "text/javascript",
+ "packages": {}
+ }
+ }
+ ],
+ "request": {
+ "method": "PUT",
+ "header": [
+ {
+ "key": "x-fapi-interaction-id",
+ "value": "47fc8e84-79f0-4003-8f25-73e9be74281c"
+ },
+ {
+ "key": "Authorization",
+ "value": "Bearer {{access_token}}",
+ "type": "text"
+ }
+ ],
+ "body": {
+ "mode": "raw",
+ "raw": "{\r\n\t\"initiator\": \"INDIVIDUAL\",\r\n\t\"reason\": \"USER_ACTION\"\r\n}",
+ "options": {
+ "raw": {
+ "language": "json"
+ }
+ }
+ },
+ "url": {
+ "raw": "{{baseUrl}}/fdx/v6/consents/{{consentId}}/revocation",
+ "host": [
+ "{{baseUrl}}"
+ ],
+ "path": [
+ "fdx",
+ "v6",
+ "consents",
+ "{{consentId}}",
+ "revocation"
+ ]
+ }
+ },
+ "response": [
+ {
+ "name": "Revoke Consent",
+ "originalRequest": {
+ "method": "PUT",
+ "header": [
+ {
+ "key": "x-fapi-interaction-id",
+ "value": "47fc8e84-79f0-4003-8f25-73e9be74281c"
+ },
+ {
+ "key": "Authorization",
+ "value": "Bearer {{access_token}}",
+ "type": "text"
+ }
+ ],
+ "body": {
+ "mode": "raw",
+ "raw": "{\r\n\t\"initiator\": \"INDIVIDUAL\",\r\n\t\"reason\": \"USER_ACTION\"\r\n}",
+ "options": {
+ "raw": {
+ "language": "json"
+ }
+ }
+ },
+ "url": {
+ "raw": "{{apiBaseUrl}}/fdx/v6/consents/{{consentId}}/revocation",
+ "host": [
+ "{{apiBaseUrl}}"
+ ],
+ "path": [
+ "fdx",
+ "v6",
+ "consents",
+ "{{consentId}}",
+ "revocation"
+ ]
+ }
+ },
+ "status": "No Content",
+ "code": 204,
+ "_postman_previewlanguage": "json",
+ "header": [
+ {
+ "key": "Date",
+ "value": "Wed, 10 Jul 2024 12:02:17 GMT"
+ },
+ {
+ "key": "X-fapi-interaction-id",
+ "value": "47fc8e84-79f0-4003-8f25-73e9be74281c"
+ },
+ {
+ "key": "Content-type",
+ "value": "application/json"
+ }
+ ],
+ "cookie": [],
+ "body": ""
+ }
+ ]
+ },
+ {
+ "name": "Get Revoked Consent history",
+ "event": [
+ {
+ "listen": "test",
+ "script": {
+ "exec": [
+ "pm.test(\"Response status code is 200\", function () {\r",
+ " pm.expect(pm.response.code).to.equal(200);\r",
+ "});\r",
+ "\r",
+ "\r",
+ "pm.test(\"Content-Type header is application/json\", function () {\r",
+ " pm.expect(pm.response.headers.get(\"Content-Type\")).to.include(\"application/json\");\r",
+ "});\r",
+ "\r",
+ "\r",
+ "pm.test(\"Response has the required fields\", function () {\r",
+ " const responseData = pm.response.json().revocations;\r",
+ "\r",
+ " pm.expect(responseData).to.be.an('array');\r",
+ " responseData.forEach(function(revocation) {\r",
+ " pm.expect(revocation.reason).to.exist;\r",
+ " pm.expect(revocation.initiator).to.exist;\r",
+ " pm.expect(revocation.updatedTime).to.exist;\r",
+ " pm.expect(revocation.status).to.exist;\r",
+ " pm.expect(revocation.status).to.equal(\"REVOKED\");\r",
+ " });\r",
+ "});\r",
+ "\r",
+ "\r",
+ "pm.test(\"Reason, initiator, updatedTime, and status are non-empty strings\", function () {\r",
+ " const responseData = pm.response.json();\r",
+ " \r",
+ " pm.expect(responseData).to.be.an('object');\r",
+ " responseData.revocations.forEach(function(revocation) {\r",
+ " pm.expect(revocation.reason).to.be.a('string').and.to.have.lengthOf.at.least(1, \"Reason should not be empty\");\r",
+ " pm.expect(revocation.initiator).to.be.a('string').and.to.have.lengthOf.at.least(1, \"Initiator should not be empty\");\r",
+ " pm.expect(revocation.updatedTime).to.be.a('string').and.to.have.lengthOf.at.least(1, \"Updated time should not be empty\");\r",
+ " pm.expect(revocation.status).to.be.a('string').and.to.have.lengthOf.at.least(1, \"Status should not be empty\");\r",
+ " });\r",
+ "});\r",
+ ""
+ ],
+ "type": "text/javascript",
+ "packages": {}
+ }
+ }
+ ],
+ "request": {
+ "method": "GET",
+ "header": [
+ {
+ "key": "x-fapi-interaction-id",
+ "value": "47fc8e84-79f0-4003-8f25-73e9be74281c"
+ },
+ {
+ "key": "Authorization",
+ "value": "Bearer {{access_token}}",
+ "type": "text"
+ }
+ ],
+ "url": {
+ "raw": "{{baseUrl}}/fdx/v6/consents/{{consentId}}/revocation",
+ "host": [
+ "{{baseUrl}}"
+ ],
+ "path": [
+ "fdx",
+ "v6",
+ "consents",
+ "{{consentId}}",
+ "revocation"
+ ]
+ }
+ },
+ "response": [
+ {
+ "name": "Get Revoked Consent history",
+ "originalRequest": {
+ "method": "GET",
+ "header": [
+ {
+ "key": "x-fapi-interaction-id",
+ "value": "47fc8e84-79f0-4003-8f25-73e9be74281c"
+ },
+ {
+ "key": "Authorization",
+ "value": "Bearer {{access_token}}",
+ "type": "text"
+ }
+ ],
+ "url": {
+ "raw": "{{apiBaseUrl}}/fdx/v6/consents/{{consentId}}/revocation",
+ "host": [
+ "{{apiBaseUrl}}"
+ ],
+ "path": [
+ "fdx",
+ "v6",
+ "consents",
+ "{{consentId}}",
+ "revocation"
+ ]
+ }
+ },
+ "status": "OK",
+ "code": 200,
+ "_postman_previewlanguage": "json",
+ "header": [
+ {
+ "key": "Date",
+ "value": "Wed, 10 Jul 2024 11:57:03 GMT"
+ },
+ {
+ "key": "Content-type",
+ "value": "application/json"
+ },
+ {
+ "key": "Content-length",
+ "value": "123"
+ }
+ ],
+ "cookie": [],
+ "body": "{\n \"revocations\": [\n {\n \"reason\": \"USER_ACTION\",\n \"initiator\": \"INDIVIDUAL\",\n \"updatedTime\": \"2024-07-10T11:46:07Z\",\n \"status\": \"REVOKED\"\n }\n ]\n}"
+ }
+ ]
+ }
+ ]
+ },
+ {
+ "name": "Refresh token",
+ "item": [
+ {
+ "name": "Get Access Token from Refresh Token",
+ "event": [
+ {
+ "listen": "test",
+ "script": {
+ "exec": [
+ "pm.test(\"Validate that the access_token, token_type, expires_in, scope, state, and grant_id fields are not null\", function () {\r",
+ " var response = pm.response.json();\r",
+ "\r",
+ " pm.expect(response.access_token).to.not.be.null;\r",
+ " pm.expect(response.token_type).to.not.be.null;\r",
+ " pm.expect(response.expires_in).to.not.be.null;\r",
+ " pm.expect(response.scope).to.not.be.null;\r",
+ " pm.expect(response.grant_id).to.not.be.null;\r",
+ "});\r",
+ "\r",
+ "pm.test(\"Extract and store the access token and refresh token in collection variable\", function () {\r",
+ " const responseData = pm.response.json();\r",
+ " \r",
+ " pm.expect(responseData.refresh_token).to.exist;\r",
+ " pm.collectionVariables.set(\"access_token\", responseData.access_token);\r",
+ "\r",
+ " pm.expect(responseData.refresh_token).to.exist;\r",
+ " pm.collectionVariables.set(\"refresh_token\", responseData.refresh_token);\r",
+ "\r",
+ "});"
+ ],
+ "type": "text/javascript",
+ "packages": {}
+ }
+ }
+ ],
+ "request": {
+ "method": "POST",
+ "header": [
+ {
+ "key": "ssl-client-verify",
+ "value": "{{ssl-client-verify}}",
+ "type": "text"
+ },
+ {
+ "key": "ssl-client-cert",
+ "value": "{{ssl-client-cert}}",
+ "type": "text"
+ }
+ ],
+ "body": {
+ "mode": "urlencoded",
+ "urlencoded": [
+ {
+ "key": "client_id",
+ "value": "{{clientId}}",
+ "type": "text"
+ },
+ {
+ "key": "grant_type",
+ "value": "refresh_token",
+ "type": "text"
+ },
+ {
+ "key": "refresh_token",
+ "value": "{{refresh_token}}",
+ "type": "text"
+ }
+ ]
+ },
+ "url": {
+ "raw": "{{baseUrl}}/fdx/auth/v1/token",
+ "host": [
+ "{{baseUrl}}"
+ ],
+ "path": [
+ "fdx",
+ "auth",
+ "v1",
+ "token"
+ ]
+ }
+ },
+ "response": [
+ {
+ "name": "Get Access Token from Refresh Token",
+ "originalRequest": {
+ "method": "POST",
+ "header": [
+ {
+ "key": "ssl-client-verify",
+ "value": "{{ssl-client-verify}}",
+ "type": "text"
+ },
+ {
+ "key": "ssl-client-cert",
+ "value": "{{ssl-client-cert}}",
+ "type": "text"
+ },
+ {
+ "key": "Authorization",
+ "value": "Bearer {{access_token}}",
+ "type": "text"
+ }
+ ],
+ "body": {
+ "mode": "urlencoded",
+ "urlencoded": [
+ {
+ "key": "client_id",
+ "value": "{{clientId}}",
+ "type": "text"
+ },
+ {
+ "key": "grant_type",
+ "value": "refresh_token",
+ "type": "text"
+ },
+ {
+ "key": "refresh_token",
+ "value": "{{refresh_token}}",
+ "type": "text"
+ }
+ ]
+ },
+ "url": {
+ "raw": "{{apiBaseUrl}}/fdx/auth/v1/token",
+ "host": [
+ "{{apiBaseUrl}}"
+ ],
+ "path": [
+ "fdx",
+ "auth",
+ "v1",
+ "token"
+ ]
+ }
+ },
+ "status": "OK",
+ "code": 200,
+ "_postman_previewlanguage": "json",
+ "header": [
+ {
+ "key": "Date",
+ "value": "Wed, 10 Jul 2024 11:52:11 GMT"
+ },
+ {
+ "key": "Content-type",
+ "value": "application/json"
+ },
+ {
+ "key": "Content-length",
+ "value": "2468"
+ }
+ ],
+ "cookie": [],
+ "body": "{\n \"access_token\": \"eyJhbGciOiJQUzI1NiIsInR5cCIgOiAiSldUIiwia2lkIiA6ICJtbkplLW1wbTRoX0puMTJRMzhOV0JaUU1xZHQzekhkS2N6ZWNkM0lKTl80In0.eyJleHAiOjE3MjA2MTI2MzEsImlhdCI6MTcyMDYxMjMzMSwiYXV0aF90aW1lIjoxNzIwNjExNzk2LCJqdGkiOiI4ZGYyYTdjNy1lODI0LTQxZmUtOGUxYi1mMjhhN2ExYzIxZTIiLCJpc3MiOiJodHRwczovL2F1dGgub3BlbmJhbmtpbmcuYXh3YXlzYnNkZXYubmV0L3JlYWxtcy9ncmlmZmluLWxpdmUiLCJzdWIiOiJiMjY4MWM1My04MjM4LTQzYWEtYTdkYi04NDhjNTQ3ZTkwODQiLCJ0eXAiOiJCZWFyZXIiLCJhenAiOiJlbW9uZXkiLCJzZXNzaW9uX3N0YXRlIjoiMTA0YjFlNTgtZTYyZS00YjRhLTk2MmQtNzk0ZGU1MWFkMWE5IiwiY25mIjp7Ing1dCNTMjU2IjoiX3JRclNzVUNuTlplc0tzZUFNX3A0Y21MMllFeG9sTXV3WkF6Nk53VjFidyJ9LCJzY29wZSI6ImZkeDphY2NvdW50ZGV0YWlsZWQ6cmVhZCBmZHg6dHJhbnNhY3Rpb25zOnJlYWQgZmR4OmFjY291bnRiYXNpYzpyZWFkIiwic2lkIjoiMTA0YjFlNTgtZTYyZS00YjRhLTk2MmQtNzk0ZGU1MWFkMWE5IiwidGVuYW50SW5mb3JtYXRpb24iOnsidGVuYW50TmFtZSI6IkdyaWZmaW4gQmFuayIsInRlbmFudElkIjoiVDAwMDEwMjUxIn0sImZkeENvbnNlbnRJZCI6IjY2OGU3M2I1YzlhZGJjMmRiNjdmMDA0ZiJ9.OqU8yKKLXFeGPXFgQhFKg3hLDkZMrFOG5dt7Qg6Jllw_0hptFCMc5q11P37j3sW5stkfCFkJdcXSVOIjyEWWBXR35F0DCggZcV6s9RZ2QTPDB6fXGGJZmhlUIMeig5YeLomKNMy6NCC1Lm2HGYtGUGQ6k470AFrhZGX0L9wpG5R5MbdYzN5jDThysOEGTDJp9l6jDC7A5Z1cNBtUD20In130iv01JRSCeaq0AGETOTrCA3FpSZZydxjAqX9rRA4zvQf8azVC79x7zljytViHO8M8thDsrUdz4joKSyUkxim0q_jgzxPEvgq687pcOD5_aXog8zYcUbC3zlDOV7N3lQ\",\n \"expires_in\": 300,\n \"refresh_expires_in\": 1800,\n \"refresh_token\": \"eyJhbGciOiJIUzUxMiIsInR5cCIgOiAiSldUIiwia2lkIiA6ICJjZDllMzI2OS0wNTM5LTQ5MTgtOWY4Yi1kM2ZkZWUwNWY2M2QifQ.eyJleHAiOjE3MjA2MTQxMzEsImlhdCI6MTcyMDYxMjMzMSwianRpIjoiYjEzZjRmZWYtN2ZjMi00ZGEyLTgxNWUtMzEyYTk4YjQwNzMyIiwiaXNzIjoiaHR0cHM6Ly9hdXRoLm9wZW5iYW5raW5nLmF4d2F5c2JzZGV2Lm5ldC9yZWFsbXMvZ3JpZmZpbi1saXZlIiwiYXVkIjoiaHR0cHM6Ly9hdXRoLm9wZW5iYW5raW5nLmF4d2F5c2JzZGV2Lm5ldC9yZWFsbXMvZ3JpZmZpbi1saXZlIiwic3ViIjoiYjI2ODFjNTMtODIzOC00M2FhLWE3ZGItODQ4YzU0N2U5MDg0IiwidHlwIjoiUmVmcmVzaCIsImF6cCI6ImVtb25leSIsInNlc3Npb25fc3RhdGUiOiIxMDRiMWU1OC1lNjJlLTRiNGEtOTYyZC03OTRkZTUxYWQxYTkiLCJjbmYiOnsieDV0I1MyNTYiOiJfclFyU3NVQ25OWmVzS3NlQU1fcDRjbUwyWUV4b2xNdXdaQXo2TndWMWJ3In0sInNjb3BlIjoiZmR4OmFjY291bnRkZXRhaWxlZDpyZWFkIGZkeDp0cmFuc2FjdGlvbnM6cmVhZCBmZHg6YWNjb3VudGJhc2ljOnJlYWQiLCJzaWQiOiIxMDRiMWU1OC1lNjJlLTRiNGEtOTYyZC03OTRkZTUxYWQxYTkifQ.jHHfE4jVgVFr1Iy-Ce37c64XYsg1YQOd14PvWNyP3tBXyLl7RiRzgnCzsR81Rui8rjcsFISty-lncrekRwLXwQ\",\n \"token_type\": \"Bearer\",\n \"not-before-policy\": 0,\n \"session_state\": \"104b1e58-e62e-4b4a-962d-794de51ad1a9\",\n \"scope\": \"fdx:accountdetailed:read fdx:transactions:read fdx:accountbasic:read\",\n \"grant_id\": \"668e73b5c9adbc2db67f004f\"\n}"
+ }
+ ]
+ }
+ ]
+ }
+ ],
+ "event": [
+ {
+ "listen": "prerequest",
+ "script": {
+ "type": "text/javascript",
+ "packages": {},
+ "exec": [
+ ""
+ ]
+ }
+ },
+ {
+ "listen": "test",
+ "script": {
+ "type": "text/javascript",
+ "packages": {},
+ "exec": [
+ ""
+ ]
+ }
+ }
+ ],
+ "variable": [
+ {
+ "key": "realmName",
+ "value": "griffin-live",
+ "type": "string"
+ },
+ {
+ "key": "authServerUrl",
+ "value": "https://auth.openbanking.axwaysbsdev.net",
+ "type": "string"
+ },
+ {
+ "key": "ssl-client-verify",
+ "value": "SUCCESS",
+ "type": "string"
+ },
+ {
+ "key": "ssl-client-cert",
+ "value": "-----BEGIN%20CERTIFICATE-----%0AMIIFbzCCA1cCFF4%2Bf1Ljv7Vo6z5ScO04IEGT1NtdMA0GCSqGSIb3DQEBCwUAMHMx%0ACzAJBgNVBAYTAklOMQwwCgYDVQQIDANERUwxDDAKBgNVBAcMA0RFTDEOMAwGA1UE%0ACgwFQVhXQVkxCzAJBgNVBAsMAk9CMQ0wCwYDVQQDDARST09UMRwwGgYJKoZIhvcN%0AAQkBFg1yb290QHRlc3QuY29tMB4XDTI0MDUxMzEyNDUyM1oXDTI1MDUxMzEyNDUy%0AM1owdTELMAkGA1UEBhMCSU4xDDAKBgNVBAgMA0RFTDEQMA4GA1UEBwwHS09MS0FU%0AQTEMMAoGA1UECgwDU0JTMQswCQYDVQQLDAJPQjENMAsGA1UEAwwESm9objEcMBoG%0ACSqGSIb3DQEJARYNam9obkB0ZXN0LmNvbTCCAiIwDQYJKoZIhvcNAQEBBQADggIP%0AADCCAgoCggIBAMNMUuz3d3osn1VYonFOeziMGQj6G6ToCot%2F6ZBL64qs2AnTRDxf%0AafBpjfuQUQAm2JDf41hONIPVJbI0IySbAQQQQvW8uzeB3LhqFT6EmgDMu6e%2Flc3g%0AM2r2DvefLHLgtbvh5jXJP33bdm34BTkT2WXp8trjYl%2F5S6J%2F5hVGn8UnvT%2FdgkdN%0AZaPu9Bpe%2B3OSg1PMz0cwdzfjq86i68Ga%2B5HkTCi979M3%2Fx95zKOdREEBhG%2FmWPz4%0AAlb5BFbCRYxaEbZcXes52LWlFUG9YjNBI%2FE2LoSSpjiHa6vL3CO3QSpjkhVGDits%0AxORn2rBqY%2Bi8duowHyBb%2B%2FIurXrEu1EHf0O9jLxF4svKPNgOk98JG464e%2BUVyJwe%0A83XxAbVnVjYPiTLv6bIlJJQU6T7wPSjHB99dyLz6bUmrcgogPfUIGZjZzJqmtllP%0A77gV%2B%2FIOIC%2FSy7Z%2F40qZvuIa1Hb3lbt%2BHgYlSE9PRHSzF%2BcJsL6X82Om%2B7xtclVb%0Ax5BJKvvQ25wN3VNsZNMDuZjN%2F81cMfKqndy95R6okAO6NIi6t7zK%2BS8dBGO0%2Bs7p%0AsERJkzATkBMvULzP08qNdfvBj0ok69CEuHvgB39H064OZNkvKLeFEqKiuIOrMkdC%0ArY4KiJvj%2FTDGqLR2L3feHJht114mq8FiRwmY4IQK7h6elMQuAM0qInEvAgMBAAEw%0ADQYJKoZIhvcNAQELBQADggIBADa0UxAQZILo%2BF%2FIZrs54AlYIFfDhU%2BnlsrKK%2FBs%0AHbJfUVrG3pVZa%2FIyVMg20vpwNJ9aU2YXlkpxW9NNp7rNhGWWW3wiS4tQgjX1wOw4%0AeZdFGsH7wpdc%2BwUlk9ZBY9Fhm7y5l2c83vZ%2B0rWxxjOm%2BEjLwPeq6s5fJXCsWKHc%0A%2FViSzBaKuZHbIGJpQmy%2BYDXKMn6H8kWJcifa4cNVK4N3y1DKYLQeAHIUBxXIgiSu%0AUzsdiguXjxcrPd3eGglUXtVl7HsSBi7HF%2FdYkPYBdOPq3%2FFH5TDV2c1ZDa9L781y%0AhZh1OQ4KkH%2FJpn%2BGGTm%2Fa%2FdrLtPPaiBWdczikBIcZX9Mj5eGMLBUT6XVTi13UISo%0ARRBtcFbHD5GnLAbeUHwUzHX%2Fyntm3BPtNe7iS%2Bq%2BOVTcxque6CnZGQRNlMEPJkWi%0AjkkCVVDBMlGimFrXowEw48XJ7vnIXg20rUVI68IeVsy7CP0Q4loyzxehDgvKktKf%0AKDwFPYbvUG%2FrSdoqxSKMIR7HZ7P4ruVRYGZ%2BN3IpjZ1u4cYtjBmWwiJ6NaljC4LG%0AX2mb7g%2Ff3sX2S48FryCv5eeMUXDHoAylb2RH%2FhbA%2BPvfbYpX5aPjw1OJqdc7LOC4%0AL6J341zcL2HlYJoMo%2FCKrvWRPzm4ExSSN%2FJlHgnFgzFs8ZsYzDBCPjlq%2BfIgl984%0Azddd%0A-----END%20CERTIFICATE-----%0A",
+ "type": "string"
+ },
+ {
+ "key": "exp",
+ "value": ""
+ },
+ {
+ "key": "request_token",
+ "value": ""
+ },
+ {
+ "key": "request_uri",
+ "value": ""
+ },
+ {
+ "key": "code",
+ "value": ""
+ },
+ {
+ "key": "access_token",
+ "value": ""
+ },
+ {
+ "key": "refresh_token",
+ "value": ""
+ },
+ {
+ "key": "consentId",
+ "value": ""
+ },
+ {
+ "key": "accountId",
+ "value": ""
+ },
+ {
+ "key": "code_verifier",
+ "value": ""
+ },
+ {
+ "key": "code_challenge",
+ "value": ""
+ },
+ {
+ "key": "login_url",
+ "value": ""
+ }
+ ]
+}
\ No newline at end of file
diff --git a/static/postman-collection/FDX-Demo-postman-environment.json b/static/postman-collection/FDX-Demo-postman-environment.json
new file mode 100644
index 00000000..aa62f92e
--- /dev/null
+++ b/static/postman-collection/FDX-Demo-postman-environment.json
@@ -0,0 +1,27 @@
+{
+ "id": "007f105e-5f27-4e12-9857-a66de46b5e91",
+ "name": "FDX Demo",
+ "values": [
+ {
+ "key": "baseUrl",
+ "value": "https://:",
+ "type": "default",
+ "enabled": true
+ },
+ {
+ "key": "clientId",
+ "value": "",
+ "type": "default",
+ "enabled": true
+ },
+ {
+ "key": "privateKey",
+ "value": "",
+ "type": "default",
+ "enabled": true
+ }
+ ],
+ "_postman_variable_scope": "environment",
+ "_postman_exported_at": "2024-09-27T09:55:20.746Z",
+ "_postman_exported_using": "Postman/11.13.1"
+}
\ No newline at end of file
diff --git a/static/sample-files/tpp1.cnf b/static/sample-files/tpp1.cnf
deleted file mode 100644
index 596d346a..00000000
--- a/static/sample-files/tpp1.cnf
+++ /dev/null
@@ -1,29 +0,0 @@
-[req]
-default_bits = 2048
-default_md = sha256
-encrypt_key = yes
-prompt = no
-string_mask = utf8only
-distinguished_name = client_distinguished_name
-req_extensions = req_cert_extensions
-
-[ client_distinguished_name ]
-businessCategory = Third Party Provider 1
-jurisdictionCountryName = BR
-serialNumber = 18505934000140
-countryName = BR
-organizationName = AXWAY
-stateOrProvinceName = SP
-localityName = São Paulo
-organizationalUnitName = 00000000-0000-0000-0000-000000000002
-UID = 00000000-0000-0000-0000-000000000002
-commonName = tpp1.demo.axway.com
-
-[ req_cert_extensions ]
-basicConstraints = CA:FALSE
-subjectAltName = @alt_name
-keyUsage = critical,digitalSignature,keyEncipherment
-extendedKeyUsage = clientAuth
-
-[ alt_name ]
-DNS = tpp1.demo.axway.com
\ No newline at end of file
diff --git a/static/sample-files/tpp2.cnf b/static/sample-files/tpp2.cnf
deleted file mode 100644
index cc5b2628..00000000
--- a/static/sample-files/tpp2.cnf
+++ /dev/null
@@ -1,29 +0,0 @@
-[req]
-default_bits = 2048
-default_md = sha256
-encrypt_key = yes
-prompt = no
-string_mask = utf8only
-distinguished_name = client_distinguished_name
-req_extensions = req_cert_extensions
-
-[ client_distinguished_name ]
-businessCategory = Third Party Provider 2
-jurisdictionCountryName = BR
-serialNumber = 18505934000140
-countryName = BR
-organizationName = AXWAY
-stateOrProvinceName = SP
-localityName = São Paulo
-organizationalUnitName = 00000000-0000-0000-0000-000000000002
-UID = 00000000-0000-0000-0000-000000000002
-commonName = tpp2.demo.axway.com
-
-[ req_cert_extensions ]
-basicConstraints = CA:FALSE
-subjectAltName = @alt_name
-keyUsage = critical,digitalSignature,keyEncipherment
-extendedKeyUsage = clientAuth
-
-[ alt_name ]
-DNS = tpp2.demo.axway.com
\ No newline at end of file