1. Introduction

The Open Finance UAE Registration Framework, grounded in the OIDC Federation principles, aims to offer detailed implementation guidelines to enhance the security and interoperability of the ecosystem. These guidelines are intended for the identification, registration, and management of OIDC Relying Parties within the Open Finance UAE Ecosystem.

Federation, as a mechanism, establishes trust between interacting federation entities (for example, a fintech application and a bank) through a trusted third party, or a Trust Anchor (the Trust Framework). This Standard delineates the interactions within this distributed trust network, known as a federation.

1.1 Requirements Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174].

1.2 Terminology

Trust Anchor: An entity that represents a trusted third party, for example, a Trust Framework provider.
Federation Entity: An entity for which it is possible to contrast a trust chain from itself to the Trust Anchor.

Trust Framework: A set of standards, protocols, and components designed to establish trust and facilitate secure data sharing between organizations. It offers a robust framework for authentication, authorization, and encryption, safeguarding data integrity and confidentiality throughout the sharing process.

Data Receiver: Entity that can access data provided by other organizations to build new products and services.

Data Provider: Entity that offers customer-permission data to other organizations (Data Receivers) in a secure and controlled way.

Relying Party (RP): An application or website that outsources its user authentication function to an IDP.

OpenID Provider (OP): Also referred to as an Identity Provider (IDP) or an authorization server. It is an entity that implemented the OIDC and OAuth protocols.

2. Rationale for Choosing OIDC Federation as Profile Foundation

This document proposes adopting the OpenID Connect (OIDC) Federation model as the underlying framework for the UAE's Registration Profile. This approach aims to streamline the data access journey, enabling Authorized Data Receivers (e.g., Fintechs Onboarded into the Trust Framework) to interact with Data Providers without the need for a pre-registration step.

OIDC Federation addresses and resolves the interoperability challenges observed in other open finance ecosystems, such as Open Finance Brazil and Open Banking UK, which rely on OAuth Dynamic Client Registration (DCR) RFC7591.

2.1 Simplifying the Data Access Path for Data Receivers

The OIDC Federation model, particularly as outlined in Section 11.1 of the OIDC Federation specification, introduces an automated registration mechanism. This allows Data Receivers to initiate Authentication Requests directly, bypassing traditional registration with Data Providers. Upon integration into the Ecosystem Trust Framework, Data Receivers are allocated a unique client_id, bound to their created encryption and transport certificates. These credentials are utilized to authenticate the Data Receiver’s requests and secure token issuance via the Data Provider's Authorization Server Endpoints.

To enable this process, Data Providers must proactively acquire relevant metadata based on their client_id from the Trust Anchor, ensuring the registered Data Receiver metadata is always up-to-date.

2.2 Reduced Interoperability Problems and Improved Standardization

The DCR framework, employed in both the Brazil’s and the UK's Open Banking implementations, necessitates that Clients ( Data Receivers ) initiate contact with the Servers ( Data Providers ) registration endpoint to onboard. This process has led to:

Problem	Solution
Varied registration requests for each Client-Server interaction, causing interoperability issues due to misprocess or miscommunication of these requests	By having Servers to automatically register clients based on the Participant Directory's Entity Statements, the system eliminates individual registration requests, enhancing interoperability.
Registration data can often be outdated as a an active PUT request against the registration endpoint is required for the Client metadata to be updated.	Implementing a server-side cache policy for registration metadata ensures timely updates, keeping client data in line with what’s defined on the Participant Directory.
Issues on the registration journey might lead to client identifiers being created without the `registration_access_token` being sent back, forcing manual recovery of tokens or removal of clients, raised using bi-lateral Service Desk tickets.	An unique, standardized `client_id` and the Trust Framework as the source of truth negates the need for client-side maintenance, streamlining the process.

2.3 Ensuring Responsibility Spread for Client Registration to the Fewest Number of Actors

Within the Proposed Registration Framework, the responsibility for registration entirely rests with the Data Providers. They are required to actively consult and regularly update data from the Trust Anchor (Trust Framework). This ensures they keep an up-to-date registry of all authorized Clients in the Ecosystem.

The Standard also specifies that when Data Providers encounter an Authentication Request from an unrecognized Data Receiver, they must fetch the client's data from the Trust Anchor. This is to accurately ascertain the client's access scopes, regardless of whether the regular updates have been properly conducted.

2.4 Cross-Border Integration Support

OIDC Federation supports the setup of unified trust network across multiple trust anchors through standardized metadata acquisition mechanisms.

This structure can be used to promote interoperability and trust among clients and servers across different ecosystems, fostering a seamless cross-border integration framework.

It’s important to note that while there is an expectation of Cross Border Integration between Open Finance UAE and other Data Sharing Ecosystems, no agreements have yet been established by CBUAE, with this being a mid to long-term objective.

3. Open Finance UAE OpenID Connect Discovery Provisions

To enhance clarity and precision in our documentation, it's important to delineate the scope of application regarding the integration between the Trust Framework and the Open Finance Hub. This section is presented as a policy statement, emphasizing that its directives are specifically tailored to the interface between these two entities. There is no broader implication for the ecosystem as a whole within this segment. The detailed requirements and protocols outlined here are pertinent solely to the Client section, which stakeholders within the ecosystem should focus on.

3.1 Authorization Server

The Authorization Server shall support OpenID Connect Discovery as required by the FAPI 2.0 Security Profile. This support shall be explicit in the Ecosystem Trust Framework configurations and the declaration of its attributes in the Discovery file (.well-known).

In addition, the Authorization Server:

Shall advertise its presence in the Open Finance UAE ecosystem by being listed on the Ecosystem Trust Framework.
Shall advertise all Open Finance UAE API resources on the Ecosystem Trust Framework.
Shall advertise support for all signing, encryption, authentication mechanisms and standards required to support the Open Finance UAE FAPI Profile.
Shall advertise mtls_endpoint_aliases as per clause 5 RFC 8705 OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens, which shall include the token_endpoint, userinfo_endpoint and push_authorization_request_endpoint.

Within the Open Finance UAE Ecosystem, the responsibility for managing the Authorization Servers falls to the API Hub. Consequently, the provisions outlined above are directly related to the integration between the Hub and the Trust Framework. This section serves as a policy statement, specifically addressing this context. It does not imply broader repercussions for the ecosystem as a whole, except as it facilitates the Discovery Process executed by the Client.

3.2 Client Application

The Client shall assume its Client Identifier to be used with all the Authorization Servers on the Ecosystem to be equal to its Entity Identifier within the Open Finance UAE Federation, as defined by the Ecosystem Trust Framework upon creation of a Software Statement Resource.

In addition, the Client:

Shall rely on ecosystem discovery services provided by the Trust Framework only.
Shall derive necessary Authorisation Server metadata by relying on an Authorization Servers OpenID Connect Discovery services only.
Shall obtain the information about the Resource Server endpoints using the Trust Framework Participants endpoint, reached on - <To be Included once the TF is Fully Live>
Shall use endpoints advertised in the mtls_endpoint_aliases authorization server’s metadata object as per clause 5 RFC 8705 OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens.

4. Open Finance UAE OpenID Connect Registration Provisions

The Authorization Server shall support the OIDC Federation with Automatic Registration.

In addition, the Authorization Server :

Shall trust all the Entity Statements issued by the “Open Finance UAE” Trust Anchor, whose entity configuration can be reached on - <To be Included once the TF is Fully Live>
Shall validate the Trust Chain Entity Statements signature using the keys supplied only by the Open Finance UAE Federation.
Shall obtain the list of authorized Relying Parties and their Entity Identifiers by using the Open Finance UAE Federation list endpoint.
Shall register the Relying Parties and issue them Client Identifiers (client_id) that have a value equal to their Entity Identifiers within the Open Finance UAE Federation.
Shall onboard all Relying Parties that have status set as “Active”
Shall deny any Token requests from Relying Parties with metadata containing status equal to “Inactive” or “Suspended”
Shall obtain the Relying Parties Entity Statements by calling their Well-Known URIs, issued by the Trust Framework, which can be obtained by appending /.well-known/openid-federation to their Entity Identifiers.
Shall only trust the information provided on the Entity Statement until the time defined on the “expiration” (exp) claim - Entity Statements are expected to
Shall maintain the integrity of all the associated consent resources, authorization grants and refresh tokens, upon successful registration of a new Relying Party and preserve the resources for a minimum duration of 30 days after either :
1. Its status has been set as Inactive or
2. The expiration of the Relying Party’s latest verified Entity Statement.
Shall maintain an updated registry of the authorized Relying Parties metadata by periodically fetching the Entity Statements and the Entity Identifiers from the Federation List Endpoint
- The maximum validity period of an Entity Statement is 24 hours. This means that the difference between the "issued at" (iat) and "expiration" (exp) claims within an Entity Statement shall not exceed 24 hours.
Shall transition clients to the suspended status if it is not possible to verify the Relying Partie’s metadata – due to the inaccessibility or corruption of the Entity Statement. In the suspended state, clients cannot be issued new access tokens but all the linked consent resources, authorization grants, and refresh tokens remain intact.
Shall verify the Entity Statement validity against the Open Finance UAE Federation Trust Chain and consider the Relying Partie’s metadata before processing the authentication request if the authorization server receives an unknown client identifier while authenticating the client.

5. Entity Statement - Relying Party Metadata

An Entity Statement contains the information needed for the Entity to participate and be subject to a Federation. The Entity Statement is signed using the private key of the issuer Entity in the form of a JSON Web Signature (JWS) [RFC7515]. The information contained inside the Entity Statement shall only be trusted once its signature has been validated using the Trust Chain of the trusted Federations Anchors.

The Following Attributes can be identified, and should be processed by Open ID Providers on the Relying Party Entity Statement Parsed JSON, under metadata.openid_relying_party:

Attributes	Type	Description	How is it Managed
`client_id`	uri	A unique identifier assigned by the authorization server to the client application upon registration. For the OIDC Federation Standard with Automatic Registration, the `client_id` must be equal to the Federation Entity Identifier.	Trust Framework
`client_name`	string	A human-readable name of the client application.	Participant
`client_uri`	uri	URL of the client application, providing information about the client. For the OIDC Federation Standard with Automatic Registration, the client URI must be equal to the Federation Entity Identifier	Trust Framework
`client_description`	string	A brief description of the client application.	Participant
`grant_types`	array of strings	The list of OAuth 2.0 grant types that the client is allowed to use for obtaining tokens, such as `authorization_code`, `client_credentials`, and other.	Regulatory Roles
`jwks_uri`	uri	URI for the Client's JSON Web Key Set Document, which contains the client’s public keys. For the CBUAE Ecosystem, the Key Sets are hosted by the Trust Framework.	Trust Framework
`logo_uri`	uri	URI of the Client Application Logo Image	Participant
`scope`	string	A space-delimited list of scopes that the client application is allowed to request.	Regulatory Roles
`redirect_uris`	array of strings	An Array containing all the `redirect_uris` that can be passed by the Client on the Authorization Request Object. This URI is used to redirect the user back to the Client once the data consumption consent is granted/denied.	Participant
`sector_identifier_uri`	uri	URI of a JSON document containing an array of `redirect_uris`	Trust Framework
`subject_type`	string	Specifies the `subject_type` that can be requested by the Client . For the CBUAE Ecosystem Public is centrally defined.	Trust Framework
`software_version`	number	Version of the Client Application	Participant
`software_id`	UUID	The Unique Identifier of the Client as defined on the Trust Framework upon its creation	Trust Framework
`organisation_id`	UUID	The Unique Identifier of the Organization that the client belongs to as defined on the Trust Framework upon the organization being onboarded	Trust Framework
`response_types`	array of strings	Specifies the `response_types` that can be requested by the client. For the CBUAE Open Finance Ecosystem, as FAPI 2.0 is used, only a response of the `code` type is permitted .	Regulatory Roles
`claims`	array of strings	A List of strings representing the claims that the Client can request to be included as part of the the ID token.	Regulatory Roles
`status`	string	The Current Status of the Client on the Trust Framework. One of: Active, Inactive, or Suspended.	Trust Framework/Participant
`use_mtls_endpoint_aliases`	Boolean	Defines if the Client is required to use the endpoints defined under the Authorisation Server Discovery Document `mtls_endpoint_aliases` attribute, or if it can use the endpoints defined on the top level of the Document	Trust Framework
`token_endpoint_auth_method`	string	Defines which OAuth Client Authentication Methods the Client can use. For the CBUAE Open Finance Ecosystem, only the `private_key_jwt`client authentication method is permitted since FAPI 2.0 is used.	Trust Framework
`authorization_detail_types`	array of strings	Defines which `authorization_detail` types can be send by the Client on the Authorization Requests.	Regulatory Roles

Attributes not defined above shall ignored by the Authorization Servers when registering existing clients as they do not serve a purpose in the Open Finance UAE Ecosystem.

The “How is it Managed” column defines how the values on a specific attribute can be updated, the three possible values are :

Regulatory Roles: This property is defined by the Regulatory Roles assigned to the Client on the Trust Framework - They will be updated once a role is assigned or revoked.
Trust Framework: This property is defined Automatically by the Trust Framework and can only be altered by the Ecosystem Global Administrators.
Participant: This property is defined by the Organization Administrators or Users when configuring the Client on the Trust Framework.

6. Non-Normative Examples

6.1 Attributes of the Relying Parties Entity Statements

The following is an example of the JSO body of a Relying Parties Entity Statement after it has been parsed from its original JWT format :

6.2 Attributes of the Federation Entity Statements

The following is an example of the json body of a Federation Entity Entity Statement, after it has been parsed from its original JWT format :

6.3 Attributes of the Federation List Endpoint

The following is an example of the return of a Federation List Endpoint, obtained on the Federation Entity Entity Statement :

7. Processing and Registering the Entity Statements on the Open Finance UAE Federation

The diagram below provides a high-level visualization of the Registration Journey expected to be undertaken by Data Providers in the Open Finance UAE Ecosystem for the Open Finance UAE Relying Parties.

8. Alternative Registration Provisions - Trust Framework Clients Endpoint

The Open Finance UAE ecosystem, in addition to supporting the OIDC Federation Standard, introduces an mTLS-protected endpoint that aggregates Relying Party Metadata into a consolidated JSON file, serving as an alternate mechanism for Authorization Servers to facilitate client onboarding within the UAE Ecosystem. This approach remains viable until integration into a broader federation necessitates a full transition to Federation Registration processes to guarantee cross-ecosystem interoperability.

The structure and accessibility of the Clients Endpoint, including the JSON Schema detailing required Relying Party Metadata fields, are delineated in the Trust Framework API Documentation. Access to this endpoint is restricted to entities possessing valid Client Certificates as issued by the Trust Framework, ensuring secure and authenticated interactions.

8.1 Clients Endpoint Registration Provisions

If the Authorization Server opts to utilize the Client Endpoint Registration Method instead of the OIDC Federation, the Authorization Server :

Shall obtain the list of list of Relying Parties, inclusive of their Client Identifiers and associated metadata, exclusively via the Open Finance UAE Trust Framework Clients Endpoint - https://matls-api.directory.openfinance.ae/clients.
Shall onboard for the active Relying Party the metadata attributes returned by the Clients Endpoint contained under “Entity Statement - Relying Party Metadata”.
Shall onboard all Relying Parties that have status set as “Active”
Shall deny any Token requests from Relying Parties with metadata containing status equal to “Inactive” or “Suspended”
Shall ensure the registry of Relying Parties and their metadata is refreshed each 6 hours at the minimum.
Shall update the metadata of all Relying Parties upon each Clients Endpoint access, contingent upon the last_updated attribute being more recent than the current registry data.
Shall maintain the integrity of all the associated consent resources, authorization grants and refresh tokens, upon successful registration of a new Relying Party and preserve the resources for a minimum duration of 30 days after its status has been set as Inactive or after its details are no longer returned on the Clients Endpoint;
Shall transition clients to the Suspended status if it is not possible to verify the Relying Partie’s metadata – due to the inaccessibility or corruption of the Entity Statement. In the suspended state, clients cannot be issued new access tokens but all the linked consent resources, authorization grants, and refresh tokens remain intact.

8.2 Non-Normative Example - Clients Endpoint

The following is an example of the JSON Payload returned by the Trust Framework clients endpoint :

Browser not supported