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 Financial-grade API, a secure OAuth profile, is designed to offer detailed implementation guidelines for enhancing security and interoperability in UAE's Open Finance APIs. This Profile, a profile of the FAPI 2.0 Security Profile, aims to streamline optionality within the framework. Additionally, it incorporates specific features to address the Consent and Authorization Requirements pertinent to Open Finance UAE use cases

Design Considerations

Security

The CBUAE security profile has been based on the FAPI 2.0 Security Profile which is an API security profile based on the OAuth 2.0 Authorization Framework [RFC6749], that aims to reach the security goals laid out in the Attacker Model [Attacker Model]. The FAPI 2.0 Security Profile has been assessed by University of Stuttgart using formal analysis methods which is available for public review. By baselining the CBUAE Security Profile on FAPI 2.0 the ecosystem is leveraging the very latest in API Security Design.

Ecosystem Interoperability

A primary goal in reducing optionality is to increase and simplify interoperability across the Ecosystem. By narrowing the range of options in the Security Profile, it aims to decrease the number of allowed variations in implementations of the FAPI 2.0 Security Profile.

While a high degree of optionality may offer Data Providers more flexibility in their Authorization Server implementation, it poses significant and material challenges for Data Receivers. Data Receivers (TPPs) must develop implementations capable of connecting to all Data Providers implementations, resulting in increased onboarding challenges and higher non-productive connectivity maintenance costs which otherwise can be spent on the delivery of value added propositions.

This move towards optionality reduction has been seen in modern Open Banking ecosystems including Open Finance Brazil and ConnectID in Australia where the FAPI 1.0 Advanced Profile was first used :

Given the above design considerations, the following recommendations are made to further profile the ‘FAPI 2.0 Security Profile’ to ensure a more interoperability domestic ecosystem:

Whilst not strictly a security consideration, to facilitate wider potential aspirations of the CBUAE ecosystem it is recommended that the ecosystem retain the use of Signed Request Objects as defined in OpenID Connect Core Section 6 and the OpenID FAPI Message Signing Profile The use of signed request objects has two main benefits, firstly it ensures that non-repudiation of Authorisation Requests is easily achieved and ensures broad interoperability for Relying Parties engaging in multiple Open Finance Initiatives around the world including the United Kingdom, Australia, The United States and Brazil.

Security Profile

Authorisation Server Considerations ( Open ID Provider )

The Authorization Server shall support the provisions specified in clause 5.3.1 of FAPI Security Profile 2.0

In addition, the Authorization Server :

1. shall only issue sender-constrained access tokens using mTLS as described in RFC8705;

2. shall ensure that the access token expiry is no longer than 10 minutes;

3. shall authenticate the confidential client using private_key_jwt;

4. shall support OAuth 2.0 Rich Authorization Requests (RAR) as a method of conveying information about the End User Authorization Request

5. shall use the query parameter as the mechanism for returning authorization response parameters as the response mode, which is the default for the code response type;

6. shall advertise support for all signing, authentication mechanisms, and standards required to support this Specification on its OpenID Connect Discovery endpoint;¶

7. shall support and verify signed request objects according to JAR [RFC9101] at the PAR endpoint [RFC9126];

8. shall require the aud claim in the request object to be, or to be an array containing, the OP's Issuer Identifier URL;

9. shall require the request object to contain an exp claim that has a lifetime of no longer than 10 minutes after the nbf claim and an nbf claim that is no longer than 10 minutes in the past.

10. shall only rely on parameters included in the signed request object passed via the request_uri parameter with the exception of client_id;

11. shall set the response header x-fapi-interaction-id to the value received from the corresponding client request header, or to a RFC4122 UUID if the request header was not provided, to track the interaction

12. shall issue refresh_tokens with an expiration period set to the same length as the expiration period of the longest consent with which the token can be used. For consents that do not have an expiry, shall issue refresh_tokens without an expiration period, or, if not technically achievable, with an expiration period greater than 100 years.

Note 1: Clause 10

Client Considerations (Relying Party)

The Authorization Server shall support the provisions specified in clause 5.3.2 of the FAPI Security Profile 2.0

1. shall support private_key_jwt as a token endpoint authentication mechanism;

2. shall include the request_uri parameter as defined in Section 6.2 of OpenID Connect Core in the authorization request

3. shall send all parameters inside the authorization request's signed request object;

4. shall sign request objects according to JAR [RFC9101] that are sent to the PAR endpoint [RFC9126];

5. shall send the aud claim in the request object as the OP's Issuer Identifier URL;

6. shall send an exp claim in the request object that has a lifetime of no longer than 10 minutes; and

7. shall send a nbf claim in the request object.

8. shall send the x-fapi-interaction-id request header, with its value being a unique RFC4122 UUID for each request, to help correlate log entries between the client and server, eg: x-fapi-interaction-id: c770aef3-6784-41f7-8e0e-ff5f97bddb3a.

Algorithm Considerations

For JWS, both clients and Authorization Servers shall use the PS256 algorithm.

For TLS, all of the Authorization Server endpoints and Resource Server shall support mTLS connections with the algorithms specified in Section 5.2 of the FAPI Security Profile 2.0

Consent and Authorization Mechanism Considerations

The Consent and Authorization Mechanism and Lifecycles to be used is specified on < Consent And Authorization Mechanism Document Link >, a Document Separate from the Open Finance UAE FAPI Profile and should be used in conjunction with this specification to ensure that clients and users can create and manage fine-grained access to resources.