Open Data Ecosystem Participation: Complete Guide

This article provides a single reference point for organizations participating in any Open Data ecosystem–finance, energy, health, or others. It explains the core concepts of Trust Frameworks and the mechanisms that enable secure open data sharing across ecosystems.

What Are Open Data Ecosystems?

Open Data ecosystems are structured environments that enable organizations to exchange data in a predictable and interoperable way. They define the technical, operational, and semantic standards that participants must follow when publishing or consuming data.

An ecosystem typically includes data providers, data receivers, and coordinating bodies that manage the ecosystem’s rules and onboarding processes. By standardizing API formats, data models, security requirements, and interaction patterns, an Open Data ecosystem ensures that independent organizations can integrate with each other without bespoke connections.

Such ecosystems are common in regulated sectors—finance, energy, and health—where consistent access to high-quality data is essential for building reliable services and ensuring interoperability across the industry.

Role of the Trust Framework in an Open Data Ecosystem

The Trust Framework provides the foundational services that enable secure and reliable data exchange between ecosystem participants. Its core responsibilities include:

• Trust Anchors–OpenID Federation or PKI with X.509 certificates

  A combination of rules, protocols, and infrastructure that enables organizations to establish mutual trust for secure data exchange.

• Participant Directory / API Portal

  Maintain a registry of all authorized participants and their permitted scopes within the ecosystem. Maintain a registry of all servers, clients, and APIs, enabling consistent discovery across the ecosystem.

• Public Key Infrastructure (PKI)

  Issue and manage TLS, signature, and encryption certificates. Provide mechanisms to validate certificates used within the ecosystem.

• Keystore

  Maintain a registry of each participant’s active cryptographic keys. These keys are used for identity validation and establishing mutual trust during interactions.

The Trust Framework does not process or store any consumer data. It serves solely as an enabler of secure interoperability between participants.

Learn more about Trust Framework.

Organizations in Open Data Ecosystems

Organizations are the primary entities in the Open Data Ecosystems. They represent real-world business entities under which users, applications, and technical resources are created and managed.

Each organization in Raidiam Connect is uniquely linked to its official registration number, ensuring a one-to-one relationship between a legal entity and its digital representation.

In addition to the governing organization(s) acting as Trust Framework Administrators, an ecosystem includes participant organi`ations that interact through published and consumed APIs.

Organization Responsibilites and Roles

Each organization’s responsibilities–whether it offers data, receives data, or performs both–are determined by the Roles assigned by the Trust Framework Administrator. These roles define how the organization participates in the ecosystem and what technical, operational, or compliance requirements it must meet.

Different participation modes often carry different obligations. For example, organizations offering data may need to implement additional security controls, expose specific API sets, or pass conformance testing. Organizations receiving data may be required to complete onboarding, register their applications, or meet minimum assurance requirements. Organizations acting in both capacities must satisfy the combined requirements.

This role-based structure ensures predictable, interoperable behaviour across the ecosystem and provides a clear basis for onboarding, certification, and governance.

Data Providers / Data Holders

Most ecosystems include organization that make data available to others. Data Providers expose datasets or APIs—typically with user consent in customer-facing scenarios, but also in machine-to-machine interactions. They must meet requirements related to security, uptime, data quality, and the API standards defined by the ecosystem.

Data Receivers / Third Party Providers (TPPs) / Data Recipents

Another common category is organization that consume data published by Data Providers. Data Receivers integrate with published APIs to build services, perform analytics, or provide customer-facing functionality. Their participation usually requires application registration, adherence to access policies, and ongoing compliance with assurance or certification requirements.

Registering Technical Resources

All participant organization can register their technical resources within the ecosystem’s Trust Platform. These resources typically include:

• Applications – client software used to access data or expose functionality.

• Authorization Servers – components responsible for handling client authentication and issuing tokens.

• APIs – endpoints published by the organisation for data access or service consumption.

Registering these resources allows the ecosystem to manage discovery, enforce security requirements, and ensure interoperability between participants.

Applications

The Applications resource allows organization to register their OpenID Relying Parties (Clients), which interact with OAuth 2.0 Authorization Servers to access protected APIs.

Each application record contains the information required for a Data Provider to identify and interact with the client. It also includes details that help consumers verify the application’s legitimacy.

info

Most information entered in the application record—such as redirect URIs, names, and descriptions—is visible to customers during the authorization process. Accuracy is critical, as these details directly affect user trust and experience.

Application Roles

Application Roles define the rights and permissions the client can have within the Open Data ecosystem. organization are initially granted roles during onboarding, which determine the technical access scopes available to their applications. When creating an application, it is essential to assign all required roles to ensure proper registration and seamless interaction with all Data Providers in the ecosystem.

Application Technical Metadata

When creating a new application, two primary technical configurations must be included to ensure the application functions as expected:

Federation Configuration

Determines whether the application participates in the Open Finance UAE Federation. The following options must be selected:

1. Federation Enabled: Choose whether the application is enabled to participate in the federation.

2. 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).

Authorization Servers

The Server resource allows organization to register their OAuth 2.0 Authorization Servers (OpenID Providers), which manage client access to participant-protected APIs.

Large Data Provider organization often operate multiple brands, security infrastructures, or IT environments tailored to different customer segments. The ecosystem must support a variety of infrastructure deployments while ensuring that all necessary services are discoverable by Data Receivers and end users.

A Data Provider organisation may register one or more servers, provided they meet the following conditions:

• Customer Recognition: The server must be identifiable by customers as a service they normally associate with the organisation.

• Token Issuance: The server must be able to issue tokens for the resources and services that a customer or Data Receiver requests access to.

Example: Server Registration for a Data Provider Organisation

Customer-Friendly Name	Well-Known Endpoint	Resource
Amazing Business Banking	https://auth.business.amazingbank.org.br/.well-known/openid-configuration	Accounts, payments
Amazing Credit-Cards	https://auth.credit-cards.amazingbank.org.br/.well-known/openid-configuration	Accounts, payments
Amazing Retail Banking	https://auth.retail.amazingbank.org.br/.well-known/openid-configuration	Accounts, payments
Amazing Insurance	https://auth.insurance.amazingbank.org.br/.well-known/openid-configuration	Insurance

In this example, the organisation “Amazing Data Provider” has published four servers on the Trust Framework. Each server is recognizable as a distinct brand. During the consent and authorization flow, customers can select the brand they associate with their services. Each server also advertises a specific set of API resources, enabling Data Receivers to discover the services offered by the organisation.

Server Technical Metadata

When registering a server, organisations must provide technical metadata to ensure that Data Receivers can discover the correct authorization and connection endpoints. Key endpoints typically include:

• Token Endpoint: Issues access tokens.

• Pushed Authorization Request (PAR) Endpoint: Initiates the user authorization flow.

• Token Introspection Endpoint: Verifies the status and details of access tokens.

All of these endpoints are published in the server’s OpenID Discovery /.well-known Endpoint

Server Discovery Metadata

When creating a new server, Data Provider organisations and TPPs provide metadata to make their servers discoverable to users and other ecosystem participants. All fields should accurately describe the server and its services to ensure proper discovery.

Field Name	Description	Example
Customer Friendly Name	The name of the organisation, branch, or service as it will appear to end users.	Global Finance - Private Banking
Description	A detailed description of the organisation, highlighting its key services and benefits. Helps users understand what the organisation offers.	Global Financial Services is a leading institution offering savings and checking accounts, loans, mortgages, and investment services.
Portal URI	The URL directing users to a webpage with more information about the organisation’s services.	https://globalfinancialservices.com
Logo URI	The URL of the organisation’s logo in PNG or JPEG format. The logo is displayed alongside the name and description on the platform.	https://www.centralbank.ae/media/ouxfisxh/banner-text-en-july28-1.png

Once registered in the Trust Framework, the server can be retrieved via the Raidiam Connect APIs, including the Participants Public API.

API Resources

API Resources define the endpoints a Data Provider exposes in a Raidiam Connect ecosystem. Correct registration enables third-party applications to discover and access shared data.

Different ecosystems or Authorization Domains may require APIs for data, consent, public access, or authorization services.

Standardization ensures consistent endpoints across Data Providers, requiring only the base URL to integrate.

Discovery automatically registers endpoints based on the API Family and Version selected, simplifying management and ensuring consistency.

Certifications

Depending on the ecosystem’s policies, organizations may be required to provide proof of conformance for technical resources, including applications, servers, or APIs.

All certifications must be registered in the Trust Framework. Each registration includes:

• Certification Type & Variant – specifies the certification track executed

• Profile Version – incremented for updates

• Certification Payload – URI to evidence supporting the certification

• Start Date – when the certification was granted

Registered certifications initially receive a Self-Certified status, pending validation. After review, the status is updated to:

• Certified – validated and active

• Rejected – invalid or insufficient evidence

• Deprecated – previously valid but now outdated

Clients or servers must obtain and register all required certifications before operating in the ecosystem. For technical resources, TLS certificates must be valid and updated at least annually.

Accessing Raidiam Connect APIs

Any registered application on the Trust Framework can access non-PII (Personally Identifiable Information) data, regardless of the roles assigned to the client.

Public APIs

Public APIs are endpoints that do not require authentication. Applications can interact with them without a TLS certificate or OAuth 2.0 authentication.

API Name	Endpoint Example	Usage
Participants	https://web.sandbox.raidiam.io/participants	Provides details about all registered servers, including: - Organisation metadata - Registered server API resources - Server general details
Keystores	https://keystore.sandbox.raidiam.io/ https://keystore.sandbox.raidiam.io/<org_id>/<app_id>/application.jwks	Provides certificates generated by the Trust Framework PKI. - For client certificates: replace <org_id> with Organisation UUID and <app_id> with Client UUID. - For server certificates: use only <org_id>.
PKI Chain	n/a	Provides issuer and root certificates in .pem format for mTLS configuration
API Resources	https://web.sandbox.raidiam.io/config/apiresources	Lists API families that can be published, including: - Endpoint regex patterns - Allowed version types - Certification expectations

Caching Strategy for Public APIs

To improve performance, implement caching when consuming public APIs. Endpoints return data that changes infrequently and include standard HTTP Cache-Control headers.

Endpoint	Description	Cache Duration	Cache-Control Header
/participants	Returns Data Provider server information, including registered API resources and metadata	15 minutes	max-age=900
/.well-known	Returns configuration details of a specific authorization server	15 minutes	max-age=900
/keystore	Provides JWKS cryptographic key material	5 minutes	max-age=300

mTLS Protected APIs

mTLS Protected APIs require applications registered with the Trust Framework and valid TLS certificates issued by authorized Certificate Authorities (CAs).

1. Access Token

   Generate an access token with the directory:software scope using the client_credentials grant type.

2. API Access

   After obtaining a token, use it for GET operations on all non-PII APIs including the client's certificate in the request.

Learn more about Security and Authentication

Create 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:

1. Click the link in the email to navigate to the Trust Framework registration page.

2. Enter your email address and follow the prompts to set up your account credentials.

note

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.

Signing 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 TF's Administration team responsible for the onboarding process.

1. View and Issue TnC Document for your legal representatives to sign.

2. Sign the issued TnC Document.

Onboard Additional Users

Organisation Administrators can onboard new Organisation Administrators as well as technical and non-technical users. For detailed guidance, see User Management.

The initial list of user types supported on the Trust Framework is shown in the table below:

User Type	Access Scope
Organisation Admin	Can manage all resources within the Organisation, including both technical and non-technical resources.
Primary Business Contact (PBC)	Can manage contacts within the Organisation. Cannot manage technical resources.
Primary Technical Contact (PTC)	Can manage all technical resources of an Organisation, including Data Providers, Applications, and Certificates.
Secondary Technical Contact (STC)	Can manage Data Providers, including adding/removing API Endpoints and Certifications. Cannot manage Applications or Certificates.

User management—including adding or removing users—can be performed through the Trust Framework platform UI. Step-by-step instructions are available here.

Additional user types can also be configured to grant access to other platforms within the Ecosystem. For example, a Primary Service Desk Contact may have access to the Ecosystem's Service Desk but would not necessarily have permissions on the Trust Framework or API Hub.

Add External IDPs

Raidiam Directory’s Just-In-Time (JIT) User Provisioning couples external Single Sign-On (SSO) with fine-grained, policy-driven permission management. The feature enables organisations to delegate user lifecycle management to their trusted Identity Providers (IDPs) while ensuring that every Directory login results in an up-to-date local user record–complete with the correct roles, group memberships, and audit metadata.

JIT enables you to bring your own IDP, bind it to an Authorisation Server, describe which email domains it governs, map IDP groups to Directory permissions, and make the platform handle the rest at authentication time.

Add External IDP

Adding Organisation Personnel to the Contacts List

Organisation Contacts allow Data Providers and TPPs to register key personnel within the Al Tareq Trust Framework. This ensures that other ecosystem participants can easily reach the appropriate departments in your organisation when needed.

Why Register Contacts?

The Organisation Contacts section is visible to all ecosystem participants and is designed to support discovery and seamless communication.

Keeping this information accurate and up to date ensures other organisations can reliably reach the right teams for technical, business, billing, incident, or security matters.

How to Add Contacts

To register a contact, navigate to the Organisation Contacts section within your organisation and provide:

• Email Address - team/group emails are also accepted (e.g., security@bank.com)

• Phone Number A direct or departmental contact number.

• Department Name Examples: Technical, Business, Billing, Security.

• Additional Information–optional–such as First Name and Last Name.

Next Steps

Once you are familiar with the concepts in this guide, proceed to the following guides to learn how to interact with other participants in the Trust Framework:

• Offer Data to Other Participants – guide for publishing your data for use by other participants.

• Get Data from Other Participants – guide for consuming data published by other participants.