Disclaimer

This document is presently in draft form and has been developed to facilitate discussions among the Open Finance United Arab Emirates (OPF-UAE) Work Groups and relevant stakeholders. It is anticipated to undergo substantial updates and revisions to refine its content and recommendations fully. Therefore, it should not be considered as final or ready for implementation as an official specification at this stage.

Version: beta.1

Introduction

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

Federation, as a mechanism, establishes trust between interacting entities (e.g., TPP and Bank) through a trusted third party, or Trust Anchor (The Trust Framework). This Standard delineates the interactions within this distributed trust network, known as a federation.

Reasoning around Selecting OIDC Federation as the base for this Profile

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 Data Receivers (e.g., Fintechs) to interact with Data Providers without the need for a pre-registration step. This method addresses and resolves interoperability challenges observed in other ecosystems, such as Open Finance Brazil and Open Banking UK, which rely on Dynamic Client Registration (DCR).

Principle	Reasoning

Principle	Reasoning
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 requests and secure token issuance via the Data Provider's Authorization Server Endpoint. To enable this process, Data Providers must proactively acquire relevant metadata based on their client_id from the Trust Anchor, ensuring the Data Receiver metadata is always up-to-date.
Reduce Interoperability problems and improve standardization	The DCR framework, employed in both Brazil 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: Varied registration requests for each Client-Server interaction, causing interoperability issues due to misprocessing or miscommunication of these requests. How this is solved : 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 How this is solved : Implementing a server-side cache policy for registration metadata ensures timely updates, keeping client data in line with what’s defined on the Participant Directroy Issues on the registration Journey might lead to client_ids 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. How this is solved : The unique, standardized client_id and the Trust Framework as the source of truth negates the need for client-side maintenance, streamlining the process.
Ensuring Responsibility Spread for Client Registration to the fewest number of actors	On 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.
Support Cross Border Integration	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.

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.

Authorization Server

The Authorization Server shall support OpenID Connect Discovery as required by 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.

Client

The Client shall assume it’s Client Identifier to be used with all the Authorisation Servers on the Ecosystem to be equal to its Entity Identifier on Open Finance UAE Federation, as defined on 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 TF is Live >
Shall use endpoints advertised in mtls_endpoint_aliases as per clause 5 RFC 8705 OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens;

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 TF is 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 authorised 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 on Open Finance UAE Federation
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 “exp” claim
shall maintain an updated registry of the authorised Relying Parties metadata by periodically fetching the Entity Statements and the Entity Identifiers from the Federation List Endpoint.
where an unknown Client Identifier is received on a Client Authentication Request the Authorisation Server shall verify the Entity Statement validity against the Open Finance UAE Federation Trust Chain properly considering the Relying Party Metadata before processing the Request.

Entity Statements

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] and 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.

Attributes of the Relying Parties Entity Statements:

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

{
  "authority_hints": [
    "https://federation.sandbox.raidiam.io/federation_entity/221a1d6c-2ab2-4b43-9baf-dd8dbda5047b",
    ,
  "exp": 1709686928,
  "iat": 1709683328,
  "iss": "https://rp.sandbox.raidiam.io/openid_relying_party/703ec16c-b1c6-479c-b01b-cbb29ba78579",
  "jwks": {
    "keys": [
      {
        "e": "AQAB",
        "n": "i6tLgmVIaFgGz9oW3AnjeOi1LG0XxnJEwWgbo5HN0KcncscvUPKAfs3LqidvTemlXvjx0gGgSbQEeh8Hz8ZzTLMrFrugzCOZkGgPhIhS4TfrdgVZDUEjf2scFYSHBUj96GTtwzZ4ojJyEiQZq6TSIr_JCNE0L2QtI5jQEiVg032KA7K2ybQQCuV0v_5zcKL37xgxxl2Et554I45Z3mOZT5E3y6VX5q-hUQlwbOr_Lpg2huBkxxvuQWeuKSZ03CkazUrP7kk7w_2tVxD_ggv8QhoihPhpmI5_ytOLWgl5Pabdfcko_HwgNMoigmBSLYjwHuhF1XO4eZPkGzIajahNxw",
        "kty": "RSA",
        "kid": "mrk-093eca7d9865403fa9e9175e609541b5"
      }
    ]
  },
  "metadata": {
    "openid_relying_party": {
      "client_id": "https://rp.sandbox.raidiam.io/openid_relying_party/703ec16c-b1c6-479c-b01b-cbb29ba78579",
      "client_name": "TestClient",
      "client_registration_types": [
        "automatic"
      ],
      "client_uri": null,
      "claims": [
        "example",
      ],
      "grant_types": [
        "client_credentials",
        "refresh_token",
        "authorization_code",
        "implicit"
      ],
      "jwks_uri": "https://keystore.sandbox.raidiam.io/d46bd24f-cc59-48c6-935a-a7724d1ab4d6/703ec16c-b1c6-479c-b01b-cbb29ba78579/application.jwks",
      "logo_uri": "https://www.aaa.jpg",
      "organization_name": "0000-federation-tests",
      "policy_uri": "https://www.policy.com",
      "redirect_uris": [
        "https://www.redirect.jpg"
      ],
      "require_signed_request_object": true,
      "response_types": [
        "code",
      ],
      "scope": "accounts credit-cards loans",
      "sector_identifier_uri": "https://keystore.sandbox.raidiam.io/d46bd24f-cc59-48c6-935a-a7724d1ab4d6/703ec16c-b1c6-479c-b01b-cbb29ba78579/redirect_uris.json",
      "software_id": "703ec16c-b1c6-479c-b01b-cbb29ba78579",
      "software_version": "1.00",
      "subject_type": "pairwise",
      "tos_uri": "https://www.tos.com"
    }
  },
  "sub": "https://rp.sandbox.raidiam.io/openid_relying_party/703ec16c-b1c6-479c-b01b-cbb29ba78579"
}

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 :

{
  "exp": 1709687032,
  "iat": 1709683432,
  "iss": "https://federation.sandbox.raidiam.io/federation_entity/221a1d6c-2ab2-4b43-9baf-dd8dbda5047b",
  "jwks": {
    "keys": [
      {
        "e": "AQAB",
        "n": "rr_yX_SnQ4aTz6DnWw8jvbIBP-gH6JLc8zvBPfDzWvv0_tdGEhxaEXM5WFT9hi1cddwD-KZ8841PVZcpiFKP9F9LxuHg4W8Cs7vYayIjNj166tysocP1gNjYR-ijt5Tx1pzCT5L9WHf9AQT-9CrpwUB4sUHfdUfPc4ohlRQd2GUMX-uSiXzhURpr6_hmDIYMIWCOL9sRY3-yikxI-ceJLnzohjpwmYjmKckvhz_ZgLxAt75hzJ35J4E7m0uZK4gs3xVBj0KnzldrPKU5UyDuKTb37OZYkkZ4tTCQB6Bt339GWk3j5OjDoAtExtFgdZnIQTQPK45x8-HNskBLayl3qQ",
        "kty": "RSA",
        "kid": "mrk-1c1da9c740ba4c628de298d73bc1f017"
      }
    ]
  },
  "metadata": {
    "federation_entity": {
      "federation_fetch_endpoint": "https://federation.sandbox.raidiam.io/federation_entity/221a1d6c-2ab2-4b43-9baf-dd8dbda5047b/fetch",
      "federation_list_endpoint": "https://federation.sandbox.raidiam.io/federation_entity/221a1d6c-2ab2-4b43-9baf-dd8dbda5047b/list",
      "homepage_uri": "https://www.raidiam.com/",
      "logo_uri": "https://www.raidiam.com/wp-content/uploads/2023/09/products-bkg.png",
      "organization_name": "Raidiam Federation",
      "policy_uri": "https://docs.connect.raidiam.io/raidiam"
    }
  },
  "sub": "https://federation.sandbox.raidiam.io/federation_entity/221a1d6c-2ab2-4b43-9baf-dd8dbda5047b"
}

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 :

[
    "https://rp.sandbox.raidiam.io/openid_relying_party/cd97ec54-0dbe-4a14-8aa0-ec8243360e3d",
    "https://rp.sandbox.raidiam.io/openid_relying_party/0a2b8426-ba92-4ecd-be5c-99a418faf766",
    "https://rp.sandbox.raidiam.io/openid_relying_party/9a19d809-5d14-4388-bcc3-c7f0cccbf9dd",
    "https://rp.sandbox.raidiam.io/openid_relying_party/8c2435c8-5823-47f6-a37d-5ea7d1b18f53",
    "https://rp.sandbox.raidiam.io/openid_relying_party/a0e2203c-079b-4448-b4bc-d0ba5c5802fd",
    "https://rp.sandbox.raidiam.io/openid_relying_party/090ee3b8-ad26-4931-a4ec-02390630f298",
    "https://rp.sandbox.raidiam.io/openid_relying_party/a75548ef-4d68-405d-83a1-25f07bfccaec",
    "https://rp.sandbox.raidiam.io/openid_relying_party/0a3e8622-9ef6-41f2-9ecc-8d788e430455",
 ]

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.

Standards Draft 0.1

This space is deprecated and no longer supported. Please use the latest available version here.

Registration Framework