Versions Compared

Version Old Version 2 New Version Current
Changes made by

Chris Michael

Erick Domingues

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Expand
titleMENU
Table of Contents
stylenone
Info
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.2

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.

...

Problem

Solution

Varied registration requests for each Client-Server interaction, causing interoperability issues due to misprocess misprocessing 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.

...

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

...

  1. Shall rely on ecosystem discovery services provided by the Trust Framework only.

  2. Shall derive necessary Authorisation Server metadata by relying on an Authorization Servers OpenID Connect Discovery services only.

  3. 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>https://data.directory.openfinance.ae/participants

  4. 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.

...

  1. 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>

  2. Shall validate the Trust Chain Entity Statements signature using the keys supplied only by the Open Finance UAE Federation.

  3. Shall obtain the list of authorized Relying Parties and their Entity Identifiers by using the Open Finance UAE Federation list endpoint.

  4. 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.

  5. Shall onboard all Relying Parties that have status set as “Active”

  6. Shall deny any Token requests from Relying Parties with metadata containing status equal to “Inactive” or “Suspended”

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

  8. Shall only trust the information provided on the Entity Statement until the time defined on the “expiration” (exp) claim - Entity Statements are expected to

  9. 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.

  10. 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.

  11. 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.

  12. 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.

...