...
gg'Additionally a User Journey diagram is provided on https://openfinanceuae.atlassian.net/wiki/spaces/TFDocsv5/pages/235077660/Trust+Framework+User+Documentation#6.3.1-Happy-Path which includes the logical steps on how a PBC and a PTC shall interact with the Trust Framework during the onboarding process.
4.1 Creating an Account
Upon being granted access to the Trust Framework (as an Organisation Administrator or Organisation User), you will receive an email with a link to the platform. Follow these steps to create your account using the same email address provided for access:
...
Field Name | Guidance | Example |
|---|---|---|
Certification Type | LFI Customer Experience - Only Existing Value | LFI Customer Experience |
Certification Type Variant | Select the type of segment for this Data Provider, in line with the validation flow that was executed on the Certification Process | Retail |
Profile Version | Provide “1” if that’s the first certification of this Variant for this Server and add +1 for each new Certification Requested/Updated | 1 |
Certification Payload | The URI of the Service Desk ticket used to obtain the Certification Request - Make sure that the Ticket Number is included on the URI Provided | https://altareqofco.atlassian.net/servicedesk/CERT-12customer/portal/2/OF-XXX |
Start Date of Certification | Data of when the Certification was Granted to the LFI | 22/08/2025 |
4.5 Creating Server Certificates
There are three types of server certificates, each serving different purposes. Detailed information about server certificates can be found in the https://openfinanceuae.atlassian.net/wiki/x/1ICQD .
Instructions on creating server certificates are available at https://docs.connect.raidiam.io/manage-certificates-for-organisation
Servers must use valid TLS certificates to protect registered resources in the Trust Framework, with a policy to update these certificates at least once every 12 months.
5. TPPs Quick Access Guide
This guide assumes that the TPP has completed the onboarding process, including submitting all required documentation and passing all necessary KYBs and KYC requirements(Once a server certification is registered on the Trust Framework, it will initially receive a “Self-Certified” status. This indicates that the Certification Reference has been registered but is still pending validation by the Nebras Trust Framework team. After registration, the Nebras team will review the evidence provided in the Certification Payload URI and update the status to one of the following: “Certified,” “Rejected,” or “Deprecated.”
The possible Certification Status values are explained below:
Certified: The certification has been validated by the Nebras Team and is currently active
Rejected: The certification is invalid due to an incorrect Certification Payload or insufficient Certification Evidence provided through the Open Finance Service Desk Jira.
Deprecated: The certification was previously valid but is now deprecated due to changes affecting the original certification.
Self-Certified: The certification payload has not yet been validated by the Nebras team. This is a provisional status.
4.5 Creating Server Certificates
There are three types of server certificates, each serving different purposes. Detailed information about server certificates can be found in the https://openfinanceuae.atlassian.net/wiki/spaces/OF/pages/50790460/Onboarding+Process#2.1-KYC%2FKYB-Prerequisites ).
There is no logical difference between Organisation Entries used by TPPs or LFIs. Therefore, the procedures for creating accounts, signing documents, and onboarding for TPPs are the same as for LFIs.
To facilitate the onboarding process, three videos have been created to provide a live demonstration of the steps TPPs need to follow for full onboarding into the Sandbox:
...
Session
...
URI
...
5.1 / 5.2
...
https://www.youtube.com/watch?v=NVQ6WJJQX_E&ab_channel=Raidiam-TrustedEcosystems%2CDelivered
...
5.3
...
https://www.youtube.com/watch?v=EGFdPQWrOP4&ab_channel=Raidiam-TrustedEcosystems%2CDelivered
...
5.4
...
...
5.4.6
...
...
5.5
...
5.1 Creating an Account
Refer to the https://openfinanceuae.atlassian.net/wiki/spaces/TFDocsv5/pages/edit-v2/235077660#4.1-Creating-an-Account section.
5.2 Signing the Terms & Conditions Document
The process for a TPP to sign the Terms & Conditions Document is similar to the process for LFIs, with the primary difference being the document type: "TPP - Terms & Conditions."
Access to the Production Environment will be granted once the document is signed and reviewed by the AlTareq team.
Refer to the https://openfinanceuae.atlassian.net/wiki/spaces/TFDocsv5/pages/edit-v2/235077660#4.2-Signing-the-Terms-%26-Conditions-Document section for more details.
5.3 Onboarding Additional Users
Refer to the https://openfinanceuae.atlassian.net/wiki/spaces/TFDocsv5/pages/edit-v2/235077660#4.3-Onboarding-Additional-Users section.
5.4 Registering Applications
The Applications Resource allows Organisations to register details of their OpenID Relying Parties (Clients), which interact with OAuth 2.0 Authorization Servers to access protected APIs. The interaction rules are outlined in the https://openfinanceuae.atlassian.net/wiki/x/TYCQD document.
When creating an Application in the Trust Framework, participants can select the regulatory roles for the client, which define the types of APIs the client can access. The instructions on how to create new Applications Can be found on https://docs.connect.raidiam.io/add-and-manage-applications
5.4.1 What is an Application
An Application (or "App") in the context of the Open Finance UAE ecosystem can be likened to an entry in an Open Finance UAE App Store. This App record holds all the information required for a Licensed Financial Institution (LFI) to identify and interact with the application. It also contains essential details that help consumers verify the legitimacy of the application.
When a new application or software statement is registered, the following process is followed:
Log in to the Directory.
Navigate to the Applications section.
Click Create New and complete the provided form.
It’s important to note that the majority of the information entered in the application form will be displayed to customers by the banks as part of the redirection or authorization process. Therefore, it is crucial to ensure that all URIs (such as redirect URIs) and descriptions are accurate and relevant to the customer audience, as these will directly impact the customer’s experience and trust in the application.
5.4.2 Roles
https://docs.connect.raidiam.io/roles dictate the rights and permissions that each Application can have on the Open Finance Schema.
Roles will be initially granted to Organisations once they are onboarded on the Ecosystem and they will reflect the Technical Access Scopes that the Applications of this Organisation can have on the Schema.
When creating an Application it’s important to include all the Roles that this Application should have in the Ecosystem to ensure it will be able to properly register with all the Data Providers in the Ecosystem
A Table Containing all the Roles and the Technical Access Scopes that they can grant on the Ecosystem can be found below :
...
Role
...
Granted to
...
Allowed API Scopes
...
Allowed Authorization Details Types
...
Allowed Grant Types
...
BSIP - Bank Service Initiation Provider
...
Participants that act as TPP for Payments and other Account-Related Services
...
openid
payments
...
urn:openfinanceuae:service-initiation-consent:*
...
client_credentials
authorization_code
refresh_token
...
BDSP - Bank Data Sharing Provider
...
Participants that act as TPP for Receiving Account Data Information
...
openid
accounts
...
urn:openfinanceuae:account-access-consent:*
...
client_credentials
authorization_code
refresh_token
...
ISP - Insurance Service Provider
...
Participants that act as TPP for Receiving Insurance Data Information or Insurance Services
...
openid
insurance
...
urn:openfinanceuae:insurance-consent:*
...
client_credentials
authorization_code
refresh_token
...
LFI - Licensed Financial Institution
...
Authorized LFIs
...
N/A
...
N/A
...
N/A
...
TSP - Technical Services Provider
...
Organisations that are providing services to the Open Finance Platform and aren’t directly acting as participants
...
N/A
...
N/A
...
N/A
5.4.3 Application Technical Metadata
When creating a new application, two primary technical configurations must be included to ensure the application functions as expected:
Federation Configuration: This section determines whether the application participates in the Open Finance UAE Federation. The following options must be selected:
Federation Enabled: Choose whether the application is enabled to participate in the federation.
Federation Managed: If federation is enabled, specify whether the application is managed as part of the federation.
Applications that provide services to end users must always be configured as Federation Enabled and Federation Managed. This ensures they operate within the Open Finance UAE Federation, allowing for secure and standardized interactions.
If the application is only intended to interact with the Trust Framework—such as executing a Single Sign-On (SSO) flow or retrieving information from other participants—it does not need to be federation-enabled. In such cases, the application should not be marked as "Federation Enabled" because federation is not required for these interactions.
Redirect_URI Field: The Redirect URI (also known as the Callback URL) is a list of endpoints specified in the client metadata. These are the URLs where the Authorization Server will redirect users after they have authenticated and authorized access to the application.
Providing the Redirect URI list ensures that the authorization code, which results from the authorization flow, is only sent to endpoints controlled by the TPP (Third-Party Provider).
5.4.4 Application Discovery Metadata
When creating a new Application, three fields will be used by the AlTareq Platforms to display the available Open Finance applications and use cases for the end users.
Those three fields should be filled out with relevant information that describes the services and the application to ensure optimal discovery by the end users.
...
Field Name
...
Field Description
...
Example
...
Client Name
...
The name of the application as it will appear to end users
...
Finance Tracker Pro
...
Description
...
A detailed description of the application, highlighting its key features, functionalities, and benefit
...
Finance Tracker Pro helps users manage their personal finances by tracking income, expenses, and savings goals. Features include budget planning, expense categorization, and financial reporting
...
Client Info URI
...
The URL pointing to the application’s webpage. This should direct users to a webpage where they can find more detailed information about the application, including its features, pricing, and support.
...
https://www.financetrackerpro.com
...
Logo URI
...
The URL pointing to the application’s logo in PNG or JPEG format. This logo will be displayed alongside the application name and description on the platform, providing a visual identifier for users.
...
https://www.financetrackerpro.com/logo.png
5.4.5 Shari’ah compliance flag
When registering/editing an Application a Field called “Flags” is available to be edited by the User.
This field will include the parameter “Shariah Compliant” with two options “True” and “False”. When registering an Application it’s required that the Shari’ah compliance information is added by the Participant on the Trust Framework (OFTF). This compliance information ensures that financial services and applications align with Shari’ah principles for users who require it.
Once registered, this information will be recovered via the Trust Framework APIs by the Data Providers on the Ecosystem, informing this on the Consent Authorization Flow.
Details about how the Shari'ah compliance will be informed to the end users can be seen on : https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1dot1final/pages/210800446/Common+Rules+and+Guidelines#21.-Shari’ah-compliance-of-TPP
5.4.6 Registering Certifications
Clients are only authorized to Operate on the Ecosystem once they have passed their full set of certifications defined on the Certification Framework, including their FAPI 2.0 UAE Relying Party Certification.
Instructions on obtaining the Certifications can be seen on the Certification Framework documentation. All Obtained Certifications must be registered on the Clients before they start executing connections to LFIs/Data Providers in production.
Instructions on how to register a Certification can be found on x/1ICQD .
Instructions on creating server certificates are available at https://docs.connect.raidiam.io/manage-certificates-for-organisation
Servers must use valid TLS certificates to protect registered resources in the Trust Framework, with a policy to update these certificates at least once every 12 months.
...
5. TPPs Quick Access Guide
This guide assumes that the TPP has completed the onboarding process, including submitting all required documentation and passing all necessary KYBs and KYC requirements(https://openfinanceuae.atlassian.net/wiki/spaces/OF/pages/50790460/Onboarding+Process#2.1-KYC%2FKYB-Prerequisites ).
There is no logical difference between Organisation Entries used by TPPs or LFIs. Therefore, the procedures for creating accounts, signing documents, and onboarding for TPPs are the same as for LFIs.
To facilitate the onboarding process, three videos have been created to provide a live demonstration of the steps TPPs need to follow for full onboarding into the Sandbox:
5.1 Creating an Account
Refer to the https://openfinanceuae.atlassian.net/wiki/spaces/TFDocsv5/pages/edit-v2/235077660#4.1-Creating-an-Account section.
5.2 Signing the Terms & Conditions Document
The process for a TPP to sign the Terms & Conditions Document is similar to the process for LFIs, with the primary difference being the document type: "TPP - Terms & Conditions."
Access to the Production Environment will be granted once the document is signed and reviewed by the AlTareq team.
Refer to the https://openfinanceuae.atlassian.net/wiki/spaces/TFDocsv5/pages/edit-v2/235077660#4.2-Signing-the-Terms-%26-Conditions-Document section for more details.
5.3 Onboarding Additional Users
Refer to the https://openfinanceuae.atlassian.net/wiki/spaces/TFDocsv5/pages/edit-v2/235077660#4.3-Onboarding-Additional-Users section.
5.4 Registering Applications
The Applications Resource allows Organisations to register details of their OpenID Relying Parties (Clients), which interact with OAuth 2.0 Authorization Servers to access protected APIs. The interaction rules are outlined in the https://openfinanceuae.atlassian.net/wiki/x/TYCQD document.
When creating an Application in the Trust Framework, participants can select the regulatory roles for the client, which define the types of APIs the client can access. The instructions on how to create new Applications Can be found on https://docs.connect.raidiam.io/add-and-manage-applications
5.4.1 What is an Application
An Application (or "App") in the context of the Open Finance UAE ecosystem can be likened to an entry in an Open Finance UAE App Store. This App record holds all the information required for a Licensed Financial Institution (LFI) to identify and interact with the application. It also contains essential details that help consumers verify the legitimacy of the application.
When a new application or software statement is registered, the following process is followed:
Log in to the Directory.
Navigate to the Applications section.
Click Create New and complete the provided form.
It’s important to note that the majority of the information entered in the application form will be displayed to customers by the banks as part of the redirection or authorization process. Therefore, it is crucial to ensure that all URIs (such as redirect URIs) and descriptions are accurate and relevant to the customer audience, as these will directly impact the customer’s experience and trust in the application.
5.4.2 Roles
https://docs.connect.raidiam.io/roles dictate the rights and permissions that each Application can have on the Open Finance Schema.
Roles will be initially granted to Organisations once they are onboarded on the Ecosystem and they will reflect the Technical Access Scopes that the Applications of this Organisation can have on the Schema.
When creating an Application it’s important to include all the Roles that this Application should have in the Ecosystem to ensure it will be able to properly register with all the Data Providers in the Ecosystem
A Table Containing all the Roles and the Technical Access Scopes that they can grant on the Ecosystem can be found below :
Role | Granted to | Allowed API Scopes | Allowed Authorization Details Types | Allowed Grant Types |
|---|---|---|---|---|
BSIP - Bank Service Initiation Provider | Participants that act as TPP for Payments and other Account-Related Services |
|
|
|
BDSP - Bank Data Sharing Provider | Participants that act as TPP for Receiving Account Data Information |
|
|
|
ISP - Insurance Service Provider | Participants that act as TPP for Receiving Insurance Data Information or Insurance Services |
|
|
|
LFI - Licensed Financial Institution | Authorized LFIs |
|
|
|
TSP - Technical Services Provider | Organisations that are providing services to the Open Finance Platform and aren’t directly acting as participants |
|
|
|
5.4.3 Application Technical Metadata
When creating a new application, two primary technical configurations must be included to ensure the application functions as expected:
Federation Configuration: This section determines whether the application participates in the Open Finance UAE Federation. The following options must be selected:
Federation Enabled: Choose whether the application is enabled to participate in the federation.
Federation Managed: If federation is enabled, specify whether the application is managed as part of the federation.
Applications that provide services to end users must always be configured as Federation Enabled and Federation Managed. This ensures they operate within the Open Finance UAE Federation, allowing for secure and standardized interactions.
If the application is only intended to interact with the Trust Framework—such as executing a Single Sign-On (SSO) flow or retrieving information from other participants—it does not need to be federation-enabled. In such cases, the application should not be marked as "Federation Enabled" because federation is not required for these interactions.
Redirect_URI Field: The Redirect URI (also known as the Callback URL) is a list of endpoints specified in the client metadata. These are the URLs where the Authorization Server will redirect users after they have authenticated and authorized access to the application.
Providing the Redirect URI list ensures that the authorization code, which results from the authorization flow, is only sent to endpoints controlled by the TPP (Third-Party Provider).
5.4.4 Application Discovery Metadata
When creating a new Application, three fields will be used by the AlTareq Platforms to display the available Open Finance applications and use cases for the end users.
Those three fields should be filled out with relevant information that describes the services and the application to ensure optimal discovery by the end users.
Field Name | Field Description | Example |
|---|---|---|
Client Name | The name of the application as it will appear to end users | Finance Tracker Pro |
Description | A detailed description of the application, highlighting its key features, functionalities, and benefit | Finance Tracker Pro helps users manage their personal finances by tracking income, expenses, and savings goals. Features include budget planning, expense categorization, and financial reporting |
Client Info URI | The URL pointing to the application’s webpage. This should direct users to a webpage where they can find more detailed information about the application, including its features, pricing, and support. | |
Logo URI | The URL pointing to the application’s logo in PNG or JPEG format. This logo will be displayed alongside the application name and description on the platform, providing a visual identifier for users. |
5.4.5 Registering Certifications
Clients are only authorized to Operate on the Ecosystem once they have passed their full set of certifications defined on the Certification Framework, including their FAPI 2.0 UAE Relying Party Certification.
Instructions on obtaining the Certifications can be seen on the Certification Framework documentation. All Obtained Certifications must be registered on the Clients before they start executing connections to LFIs/Data Providers in production.
Instructions on how to register a Certification can be found on https://docs.connect.raidiam.io/manage-application-certifications .
Use the following table as a reference of what must be provided when a new Certification is registered:
Field Name | Guidance | Example |
|---|---|---|
Certification Type | Select one of the three potential certification types for TPPs - Functional, Security or Customer Experience | TPP FAPI Certification |
Certification Type Variant | Select the Variant Type of this Certification, that is, which track was executed when running the Certification Process - Note that for most certifications only one value is set | FAPI 2.0 UAE RP |
Profile Version | Provide “1” if that’s the first certification of this Variant for this Server and add +1 for each new Certification Requested/Updated | 1 |
Certification Payload | For Nebras Issued Certifications : The URI of the Service Desk ticket used to obtain the Certification Request - Make sure that the Ticket Number is included on the URI Provided For OIDF Issued Certifications : The URI of the Certification Package as presented on https://openid.net/certification/ | |
Start Date of Certification | Data of when the Certification was Granted by either Nebras or the OIDF - For the OIDF this value must match the one presented on their Certification Page | 22/08/2025 |
Once a client certification is registered on the Trust Framework, it will initially receive a “Self-Certified” status. This indicates that the Certification Reference has been registered but is still pending validation by the Nebras Trust Framework team. After registration, the Nebras team will review the evidence provided in the Certification Payload URI and update the status to one of the following: “Certified,” “Rejected,” or “Deprecated.”
The possible Certification Status values are explained below:
Certified: The certification has been validated by the Nebras Team and is currently active
Rejected: The certification is invalid due to an incorrect Certification Payload or insufficient Certification Evidence provided through the Open Finance Service Desk Jira.
Deprecated: The certification was previously valid but is now deprecated due to changes affecting the original certification.
Self-Certified: The certification payload has not yet been validated by the Nebras team. This is a provisional status.
5.5 Creating Client Certificates
There are three types of client certificates, each with specific use cases. Detailed information about client certificates can be found in the https://openfinanceuae.atlassian.net/wiki/x/1ICQD
Instructions on creating server certificates are available at https://docs.connect.raidiam.io/manage-application-certifications . For the “Certification Payload” field, the Participant is expected to provide the URI that points to the .zip file provided on the OIDF Certification Table, for the FAPI 2 RP - UAE Profile
Use the following table as a reference of what must be provided when a new Certification is registered:
...
Field Name
...
Guidance
...
Example
...
Certification Type
...
Select one of the three potential certification types for TPPs - Functional, Security or Customer Experience
...
TPP FAPI Certification
...
Certification Type Variant
...
Select the Variant Type of this Certification, that is, which track was executed when running the Certification Process - Note that for most certifications only one value is set
...
FAPI 2.0 UAE RP
...
Profile Version
...
Provide “1” if that’s the first certification of this Variant for this Server and add +1 for each new Certification Requested/Updated
...
1
...
Certification Payload
...
For Nebras Issued Certifications : The URI of the Service Desk ticket used to obtain the Certification Request - Make sure that the Ticket Number is included on the URI Provided
For OIDF Issued Certifications : The URI of the Certification Package as presented on https://openid.net/certification/
...
...
Start Date of Certification
...
Data of when the Certification was Granted by either Nebras or the OIDF - For the OIDF this value must match the one presented on their Certification Page
...
22/08/2025
5.5 Creating Client Certificates
There are three types of client certificates, each with specific use cases. Detailed information about client certificates can be found in the https://openfinanceuae.atlassian.net/wiki/x/1ICQD
Instructions on creating server certificates are available at certificates-for-application
Servers must validate the certificates and signatures used by clients on each new connection and authentication request. If a client uses a revoked or expired certificate, the server will deny the request.
5.6 Shari’ah compliance flag
When onboarded into the ecosystem, the PBC can configure organization-level “Flags” that are editable by the user.
One of these flags includes the parameter “Shariah Compliant”, which has two options: “True” or “False.” Before connecting with data providers, participants must add the Shari’ah compliance information to the Trust Framework (OFTF).
Once registered, this information will be retrieved by data providers in the ecosystem via the Trust Framework APIs and reflected in the Consent Authorization Flow.
For more details on how Shari’ah compliance is communicated to end users, refer to the following link: https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1dot1final/pages/210800446/Common+Rules+and+Guidelines#21.-Shari%E2%80%99ah-compliance-of-TPP
5.7 Connecting with Data Providers
Once client certificates are created, TPPs can start accessing customer data/services by connecting to the registered Authorization Servers and Resource Servers using the provided credentials.
5.7.1 Data Providers Discovery
The first step is to discover all the resources registered by the LFIs in the Directory, which can be done using the Participants Public API - https://docs.connect.raidiam.io/receive-data#l9cWY / https://docs.connect.raidiam.io/manage-certificates-for-application
Servers must validate the certificates and signatures used by clients on each new connection and authentication request. If a client uses a revoked or expired certificate, the server will deny the request.
5.6 Connecting with Data Providers
Once client certificates are created, TPPs can start accessing customer data/services by connecting to the registered Authorization Servers and Resource Servers using the provided credentials.
5.6.1 Data Providers Discovery
The first step is to discover all the resources registered by the LFIs in the Directory, which can be done using the Participants Public API - https://docs.connect.raidiam.io/receive-data#l9cWY / https://docs.connect.raidiam.io/find-data-providers-via-public-api
The Participant's Public APIs provide a single response in JSON format that contains information about all the Data Providers registered on the Ecosystem, including all their metadata and API Information, allowing a single call to provide all the information about who offers what product and the endpoint to access it on the AlTareq Platform.
The Technical Requirements around API and Server discovery are outlined on the security standards, on the https://openfinanceuae.atlassian.net/wiki/x/i4CQD
5.6.2 Establishing Connection with Servers
After retrieving all the resources, clients can call the Authorization Server token and PAR endpoints, as outlined in the find-data-providers-via-public-api
The Participant's Public APIs provide a single response in JSON format that contains information about all the Data Providers registered on the Ecosystem, including all their metadata and API Information, allowing a single call to provide all the information about who offers what product and the endpoint to access it on the AlTareq Platform.
The Technical Requirements around API and Server discovery are outlined on the security standards, on the https://openfinanceuae.atlassian.net/wiki/x/i4CQD
5.7.2 Establishing Connection with Servers
After retrieving all the resources, clients can call the Authorization Server token and PAR endpoints, as outlined in the https://openfinanceuae.atlassian.net/wiki/x/TYCQD document.
Note: Clients are not required to undergo an active registration step in the Registration Framework; servers will accept all incoming valid requests from clients.
6 Additional Information
This section provides insights into aspects of the Trust Framework that go beyond the data exchange processes between LFIs and TPPs, offering a broader view of the platform’s capabilities.
6.1 Organisation Flags
Once a participant is onboarded into the Trust Framework, the Nebras team configures a set of metadata flags known as "Organisation Flags." These flags indicate whether an institution supports certain services or products that fall outside the current scope of Open Finance but may be relevant for future integrations. For example, an institution might support "House Insurance Policies" but may not have an active API family for these products yet. The development of APIs for such services could still be in progress.
In essence, Organisation Flags outline the expected products or services that an LFI should share, while https://openfinanceuae.atlassian.net/wiki/x/TYCQD document.
Note: Clients are not required to undergo an active registration step in the Registration Framework; servers will accept all incoming valid requests from clients.
6 Additional Information
This section provides insights into aspects of the Trust Framework that go beyond the data exchange processes between LFIs and TPPs, offering a broader view of the platform’s capabilities.
6.1 Organisation Flags
Once a participant is onboarded into the Trust Framework, the Nebras team configures a set of metadata flags known as "Organisation Flags." These flags indicate whether an institution supports certain services or products that fall outside the current scope of Open Finance but may be relevant for future integrations. For example, an institution might support "House Insurance Policies" but may not have an active API family for these products yet. The development of APIs for such services could still be in progress.
In essence, Organisation Flags outline the expected products or services that an LFI should share, while https://openfinanceuae.atlassian.net/wiki/spaces/TFDocsv5/pages/235077660/Trust+Framework+User+Documentation#4.4.4-Registering-API-Resources reflect what they are currently sharing.
Flags included on the Trust Framework Participants can be reviewed under the "Flags" object via the spaces/TFDocsv5/pages/235077660/Trust+Framework+User+Documentation#4.4.4-Registering-API-Resources reflect what they are currently sharing.
Flags included on the Trust Framework Participants can be reviewed under the "Flags" object via the https://docs.connect.raidiam.io/participants-api
6.2 Accessing Data from the Trust Framework
Any registered application on the Trust Framework can access non-PII (Personally Identifiable Information) data, regardless of the roles assigned to the client. Here's how to retrieve this data:
6.2.1 Public APIs
Public APIs are endpoints that don't require authentication, allowing any application to interact with them without using a TLS certificate or undergoing OAuth 2.0 authentication. Below are the available public APIs in the Trust Framework:
API Name | Endpoint | Usage | Instructions / Swagger |
|---|---|---|---|
Participants | Sandbox : https://data.sandbox.directory.openfinance.ae/participants Production : https://data.directory.openfinance.ae/participants | Provides details about all the Servers that have been registered on the Trust Framework, including :
| https://docs.connect.raidiam.io/find-data-providers-via-public-api |
...
6.2 Accessing Data from the Trust Framework
Any registered application on the Trust Framework can access non-PII (Personally Identifiable Information) data, regardless of the roles assigned to the client. Here's how to retrieve this data:
6.2.1 Public APIs
Public APIs are endpoints that don't require authentication, allowing any application to interact with them without using a TLS certificate or undergoing OAuth 2.0 authentication. Below are the available public APIs in the Trust Framework:
API Name | Endpoint | Usage | Instructions / Swagger | ||
|---|---|---|---|---|---|
Participants | |||||
Keystores | Sandbox : https://keystore.sandbox.directory.openfinance.ae/<org_id>/<app_id>/application.jwks Production : https://keystore.directory.openfinance.ae/<org_id>/<app_id>/application.jwks | Provides details about the certificates generated by the Trust Framework PKI. To verify details about client certificates, replace the <org_id> with the value of the Organisation UUID of the participant on the TF and the <app_id> with the value of the Client UUID To verify details about server certificates, remove the <app_id> from the URI path and provide only the the <org_id> with the value of the Organisation UUID of the participant | https://docs.connect.raidiam.io/public-and-private-keys#bz_0v | ||
PKI Chain | Sandbox : https://dataopenfinanceuae.sandbox.directory.openfinance.ae/participantsatlassian.net/wiki/spaces/standardsv1dot1final/pages/210796756/Certificate+Standard#4.2-Sandbox-Environment Production : https://dataopenfinanceuae.directory.openfinance.ae/participants | Provides details about all the Servers that have been registered on the Trust Framework, including :
| https://docs.connect.raidiam.io/find-data-providers-via-public-api atlassian.net/wiki/spaces/standardsv1dot1final/pages/210796756/Certificate+Standard#4.1-Production-Environment | Provides the issuer and root certificates in | https://docs.connect.raidiam.io/participantspublic-key-apiinfrastructure#lwJo2 |
KeystoresAPI Resources | Sandbox : https://keystoreweb.sandbox.directory.openfinance.ae/<org_id>/<app_id>/application.jwksconfig/apiresources Production : https://keystoreweb.directory.openfinance.ae/<org_id>/<app_id>/application.jwks Provides details about the certificates generated by the Trust Framework PKI. To verify details about client certificates, replace the <org_id> with the value of the Organisation UUID of the participant on the TF and the <app_id> with the value of the Client UUID To verify details about server certificates, remove the <app_id> from the URI path and provide only the the <org_id> with the value of the Organisation UUID of the participant.ae/config/apiresources | Provides the list of API Families that can be published on the TF. This API returns a JSON file which includes:
| https://docs.connect.raidiam.io/public-and-private-keys#bz_0v | PKI Chain | Production : api-resources |
6.2.2 mTLS Protected APIs
The mTLS Protected APIs can only be accessed by Applications that have been registered with the Trust Framework and hold valid TLS/Transport issued by authorized Certificate Authorities (CAs) within the Trust Framework.
Instructions on how to generate an Application are described on https://openfinanceuae.atlassian.net/wiki/spaces/
...
...
Provides the issuer and root certificates in .pem format for configuring mTLS
235077660/Trust+Framework+User+Documentation#5.4-Registering-Applications
To access these protected APIs, the participant must first generate an access token with the directory: software scope by calling the token endpoint using the client_credentials grant type. Instructions for obtaining the token can be found on https://docs.connect.raidiam.io/
...
client-credentials-flow-obtain-access-token#YzDfh
Token Endpoints:
Sandbox: https://
...
After obtaining the access token, it can be used to access GET operations for all Trust Framework APIs that do not return personal data.
The Swagger documentation for the TF API is available here: https://
...
...
...
...
Provides the list of API Families that can be published on the TF.
This API returns a JSON file which includes:
The API Families that can be published
The expected endpoint regular expression
The Allowed version types
The Certification Expectation if any
...
https://docs.connect.raidiam.io/api-resources
6.2.2 mTLS Protected APIs
The mTLS Protected APIs can only be accessed by Applications that have been registered with the Trust Framework and hold valid TLS/Transport certificates issued by authorized Certificate Authorities (CAs) within the Trust Framework.
Instructions on how to generate an Application are described on https://openfinanceuae.atlassian.net/wiki/spaces/TFDocsv5/pages/235077660/Trust+Framework+User+Documentation#5.4-Registering-Applications
To access these protected APIs, the participant must first generate an access token with the directory: software scope by calling the token endpoint using the client_credentials grant type. Instructions for obtaining the token can be found on https://docs.connect.raidiam.io/client-credentials-flow-obtain-access-token#YzDfh
Token Endpoints:
Sandbox: https://matls-auth.sandbox.directory.openfinance.ae/token
Production: https://matls-auth.directory.openfinance.ae/token
After obtaining the access token, it can be used to access GET operations for all Trust Framework APIs that do not return personal data.
The Swagger documentation for the TF API is available here: https://api.connect.raidiam.io/source.yaml
The API Host URls are:
...
The API Host URls are:
An example request against the Trust Framework Protected APIs can be found https://docs.connect.raidiam.io/find-all-applications
6.3 User Journey Diagrams
This Session includes the expected User Journeys for the users that are onboarding into the Trust Framework.
6.3.1 User Journey - Happy Path
| Inc drawio | ||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
6.3.2 User Journey - Unhappy Paths
| Inc drawio | ||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|