...
This document aims to explain the role of the Trust Framework in the Open Finance UAE Program and how technical users from LFIs and TPPs are expected to interact with it. Its content is derived from the https://docs.connect.raidiam.io/ Documentation, which is referenced multiple times within this document.
The Sandbox Trust Framework can be accessed at the following link: https://web.sandbox.directory.openfinance.ae/
The Production Trust Framework can be accessed at the following link: https://web.directory.openfinance.ae/
The Sandbox and the Production environments are functionally the same, with the Sandbox environment serving as a testing ground for institutions to use before they start consuming/publishing APIs on the Production Environment.
2. Role of the Trust Framework
The Trust Framework enables secure data sharing between LFIs and TPPs by providing functionalities around API discovery, client onboarding and client authentication functionalities. Key roles executed by the Trust Framework in the ecosystem include:
Trust Anchors:
Provide a registry of authorized participants and their scope of access scope within the ecosystem.
API Portal:
Provide a registry of all the servers, clients, and APIs that are currently live within in the ecosystem.
Keystore:
Provide a registry of all active keys for each participant, allowing them to recover those keys and use them to validate each other's identity, enabling trust—a key requirement for data sharing.
PKI:
A public key infrastructure that enables the issuance and management of TLS, signature, and encryption certificates.
Provides mechanisms to verify the certificates generated on the platform PKI.
...
LFIs, or users acting on behalf of LFIs, need to execute the following actions on the Trust Framework:
Sign Participation Documents
To fully onboard on the Ecosystem all participants - LFIs, TPPs and VASPs, are expected to issue and sign the Ecosystem participation Document on Docusign.
Ensure Server Certificates are Valid:
Generate transport, signing and encryption certificates on the Trust Framework; rotating them at least once every 12 months (certificate expiration is set at 13 months).
Ensure Published APIs are Valid and Certified:
Publish the API endpoints and ensure the correct version is available before any defined ecosystem go-live date.
Ensure server metadata is always up to date, including server logo, server description and customer-facing name.
Integrate with Directory for Onboarding:
Integrate with the Trust Framework registration endpoints, ensuring all clients registered are onboarded and validated following the ecosystem Registration Framework
Integrate Authentication:
Integrate with the Trust Framework JWKS endpoints, recovering client public keys when validating message signatures and executing message encryption.
Integrate with the Directory OCSP/CRL services, verifying that used certificates are valid and up-to-date.
...
This guide assumes that the LFI has been fully onboarded to the ecosystem, having submitted all required documentation and passed all necessary KYBs and KYC requirements for entry into the ecosystem.
4.1 Creating an Account
Once a user has been Upon being granted access to the Trust Framework (granted after being added as either an Organization Administrator or Organization User), the user you will receive an email with a link to the Trust Framework. The user must create an platform. Follow these steps to create your account using the same email address added to the platformprovided for access:
Click the link in the email to navigate to the Trust Framework registration page.
Enter your email address and follow the prompts to set up your account credentials.
The image below presents illustrates the steps the user is expected to take when registering for the first time, registration steps for first-time users or when logging in to the platform:
...
Important: The Sandbox and Production environments of the Trust Framework use separate Identity Providers (IDPs). Therefore, you must complete two separate registrations: one for the Sandbox environment and another for the Production environment.
4.2 Signing
...
< This section requires definitions around the Terms and Conditions that need to be signed during the Participant Onboarding Process - Currently under definition >
...
the Terms & Conditions Document
As part of the Ecosystem Registration process, the First Primary Business Contact (PBC) of the Institution, upon receiving access to the Sandbox Trust Framework, must issue the Ecosystem Terms & Conditions Document. This document requires signatures from the legal representatives of the Institution.
Access to the Production Environment will be granted once this document is signed by the legal representatives and validated by the AlTareq team responsible for the onboarding process.
Issuing the Document - PBC :
The image below outlines the steps the PBC should follow when issuing the Ecosystem Participation Document:
Important: The Legal Representatives appointed on the process above are required to have enough powers to represent the Institutions as defined on the Institution’s Statutory Documents.
Signing the Document - Legal Representatives :
The appointed legal representatives will receive an email prompting them to sign the document via DocuSign.
The process to sign the document should be straightforward, with each representative being required to click on the “Review Document” button on the Docusign E-mail and follow the steps on the screen.
Validation and Receiving Production TF Access:
Once the document is signed by all legal representatives, the AlTareq team will validate it.
Upon confirmation of the signatures, the appointed PBC will also be granted access to the Production Environment, where they can now onboard additional users.
For more information on the Terms and Conditions and how the Directory handles them, please refer to the documentation available at https://docs.connect.raidiam.io/terms-and-conditions .
4.3 Onboarding Additional Users
Organization Administrators and certain types of can onboard new Organisation Administrators as well as technical https://docs.connect.raidiam.io/users , such as PBCs and PTCs, can onboard other Organization Administrators and technical users. Newly added users have the same scope as existing users. Adding/ .
The List of Users Supported on the Trust Framework can be seen on the table below :
User Type | Access Scope |
|---|---|
Organisation Admin | Can Manage all the resources on the Organisation, Technical and Non-Technical |
Primary Business Contact (PBC) | Can Manage Contacts on the Organisation. Cannot Manage Technical Resources |
Primary Technical Contact (PTC) | Can Manage all Technical Resources of an Organisation - Data Providers, Applications and Certificates |
Secondary Technical Contact (STC) | Can Manage Data Providers, adding and removing API Endpoints and Certifications. Cannot Manage Applications and Certificates |
User management, including adding or removing users in the Trust Framework, can be done using the platform UI following the instructions defined . Detailed instructions can be found at https://docs.connect.raidiam.io/add-users
Additional User types can be configured on the platform to grant access to other platforms of the Ecosystem, like, for example, a “Primary Service Desk Contact", which would have access to the AlTareq Service Desk, but not necessarily anything on the Trust Framework or the Api Hub.
4.4 Registering Servers and APIs
LFIs are expected to maintain responsible for maintaining an up-to-date registry of their https://docs.connect.raidiam.io/authorisation-servers and https://docs.connect.raidiam.io/api-resources that they currently support on the Open Finance Schema. LFIs must ensure that only Only valid and accessible resources are should be included in the Trust Framework to ensure an interoperable data access journey by for TPPs.
4.4.1 Registering
...
a Data Provider
The Authorization Server Data Provider Resource allows organizations to register details of their OAuth 2.0 Authorization Servers (Open ID Providers), which manage client access from clients to the participant-protected APIs. The interaction rules on how clients interact with the between clients and Authorization Server endpoints are outlined in the CBUAE FAPI 2.0 Standards.
Once included registered in the Trust Framework, the Authorization Server and API data can be obtained using accessed via the Trust Framework APIs, notably the Participants Public API.
Instructions on how to include register an Authorization Server in the Trust Framework can be found at https://docs.connect.raidiam.io/add-authorisationdata-serverprovider
4.4.2 Registering API Resources
The Trust Framework enables participants to include API Resources Participants can register https://docs.connect.raidiam.io/xwL5-api-resources for the products and services they offer on the schema. Participants can add to the Trust Framework only Only approved API endpoints and respective versions approved for go-live in the ecosystem.The should be added to the Trust Framework.
Details about the API resources can be obtained through the same Participants Public API that provides information about servers can be used to obtain details about the API resourcesused for server information.
Instructions on how to add and maintain API resources can be found are available at https://docs.connect.raidiam.io/manage-apis-for-discovery-and-integration
4.5 Creating Server Certificates
There are three types of server certificates, each with serving different use casespurposes. Details Detailed information about the server certificates are defined can be found in the Certificate Standard document at https://openfinanceuae.atlassian.net/wiki/x/9ICFBg .
Instructions on how to create creating server certificates can be found are available at https://docs.connect.raidiam.io/manage-certificates-for-organisation
Servers are required to must use valid TLS certificates to protect the registered resources registered in the Trust Framework, and with a policy for updating to update these certificates at least once every 12 months must be set in place.
...
5. TPPs Quick Access Guide
This guide assumes that the TPP has been fully onboarded to the ecosystem, having submitted completed the onboarding process, including submitting all required documentation and passed passing all necessary KYBs and KYC requirements for entry into the ecosystem.
There is no logical difference between Organization Entries used by TPPs or LFIs. Therefore, details around the procedures for creating accounts, signing documents, and onboarding for TPPs are the same as for LFIs.
5.1 Creating an Account
Please refer Refer to the https://openfinanceuae.atlassian.net/wiki/spaces/TFDocsv1TFDocsv2/pages/edit-v2/117801029#4124387349#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/TFDocsv1TFDocsv2/pages/edit-v2/117801029#4124387349#4.2-Signing-the-Terms-Ecosystem%26-ParticipationConditions-Document section for more details.
5.3 Onboarding Additional Users
Please refer Refer to the https://openfinanceuae.atlassian.net/wiki/spaces/TFDocsv1TFDocsv2/pages/117801029/Trust+Framework+User+Documentation#4edit-v2/124387349#4.3-Onboarding-Additional-Users section.
5.4 Registering
...
Applications
The Client Applications Resource enables allows organizations to register details of their OpenID Relying Parties (Clients), which will interact with OAuth 2.0 Authorization Servers to access protected APIs. The interaction rules between clients and Authorization Server endpoints are outlined in the Security Profile - FAPI document at https://openfinanceuae.atlassian.net/wiki/x/TYCFBg document.
When a client is created creating an Application in the Trust Framework, the participant participants can select which the regulatory roles for the client has. These roles will define what , 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 Roles
https://docs.connect.raidiam.io/roles dictate the rights and will be validated during the client authentication process by the server whenever it requests access to an API.Instructions on how to add and maintain API resources can be found at 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 | Allowed API Scopes | Allowed Authorization Details Types | Allowed Grant Types |
|---|---|---|---|
TBD |
|
|
|
5.4.2 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.
User Type | Access Scope | Example |
|---|---|---|
Organisation Admin | Can Manage all the resources on the Organisation, Technical and Non-Technical | |
Primary Business Contact (PBC) | Can Manage Contacts on the Organisation. Cannot Manage Technical Resources | |
Primary Technical Contact (PTC) | Can Manage all Technical Resources of an Organisation - Data Providers, Applications and Certificates | |
Secondary Technical Contact (STC) | Can Manage Data Providers, adding and removing API Endpoints and Certifications. Cannot Manage Applications and Certificates |
5.4.3 Registering FAPI-RP Certifications
Clients are only authorized to Operate on the Ecosystem once they have passed their FAPI 2.0 UAE Relying Party Certification.
Instructions on how to obtain the FAPI-RP Certification can be seen on the Certification Tab of the Documentation.
Instructions on how to register a Certification can be found on https://docs.connect.raidiam.io/manage-apis-for-discovery-and-integrationapplication-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
5.5 Creating Client Certificates
There are three types of client certificates, each with different specific use cases. Details Detailed information about the client certificates are defined can be found in the Certificate Standard document at https://openfinanceuae.atlassian.net/wiki/x/9ICFBg
Instructions on how to create creating server certificates can be found are available at https://docs.connect.raidiam.io/manage-certificates-for-organisation
Servers are expected to must validate the certificates and signatures used by clients on every each new connection and authentication request. If a client uses a revoked or expired certificate, the server will promptly deny the incoming request.
5.6 Obtaining Data
Once the client certificates have been are created, the TPP TPPs can start obtaining accessing customer data/services by accessing connecting to the registered Authorization Servers and Resources Resource Servers using the created provided credentials.
5.6.1 Data Providers Discovery
The first step in this journey is to discover all the resources registered by the LFIs in the Directory. This , which can be done using the Participants Public API, following . Follow the discovery guidelines defined in the Registration Framework at https://openfinanceuae.atlassian.net/wiki/x/roCFBg Once
5.6.2 Connecting with Servers
After retrieving all the resources have been retrieved, the client should be able to , clients can call the Authorization Server token and PAR endpoints, as outlined in the Security Profile - FAPI document at https://openfinanceuae.atlassian.net/wiki/x/TYCFBgIt’s worth noting that there is no need for
Note: Clients are not required to undergo an active registration step by the clients in the Registration Framework, meaning that servers are expected to ; servers will accept all incoming valid requests from clients.