Versions Compared

Version Old Version 1 New Version Current
Changes made by

Chris Michael

Erick Domingues

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

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

Table of Contents

Table of Content Zone
minLevel1
maxLevel7
locationtop

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

2. Security Profile

2.1 Authorisation Server Considerations ( Open ID Provider )

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

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 cache clients jwks_uris for a maximum period of 20 minutes.

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

  6. Shall only process authorization requests if the type specified in the authorization_details attribute matches any of the types listed in the authorization_detail_types metadata attribute of the Relying Party.

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

  8. Shall advertise support for all signing, authentication mechanisms, and standards required to support this Specification on its OpenID Connect Discovery (.well-known) endpoint.

  9. Shall support and require signed request objects according to the OAuth JWT-Secured Authorization Request (JAR) [RFC9101] at the PAR endpoint [RFC9126].

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

  11. 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 not more than 10 minutes in the past.

  12. Shall only rely on the parameters included in the signed request object passed via the request_uri parameter except for the client_idparameter.

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

  14. 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 period, the authorization server shall issue refresh_tokens without an expiration period, or, if not technically achievable, with an expiration period greater than 100 years.

2.2 Client Considerations (Relying Party)

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

  1. Shall support private_key_jwt as a token endpoint authentication mechanism (client authentication method).

  2. Shall include the request_uri parameter in the authorization request as defined in the 6.2 section of OpenID Connect Core specification.

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

  4. Shall support and require signed request objects according to the OAuth JWT-Secured Authorization Request (JAR) [RFC9101] at 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;

  7. Shall send an 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, e.g: x-fapi-interaction-id: c770aef3-6784-41f7-8e0e-ff5f97bddb3a.

2.3 Algorithm Considerations

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

For TLS, all of the Data Provider’s Authorization Server endpoints and Resource Server endpoints shall support mTLS connections with the algorithms specified in the 5.2 section of the FAPI 2.0 Security Profile.

2.4 Consent and Authorization Mechanism Considerations

The Open Finance UAE leverages Rich Text Authorization Requests (RAR) to enable the granularity level required for the Open Finance Consents and Use Cases.

The Consent and Authorization Mechanism and lifecycle details are specified in the “Authentication and Authorization Document”.

The schema for the authorization_details attribute of the RAR payload can be identified on :

  • The "Bank Service Initiation API - Swagger " for the urn:openfinanceuae:service-initiation-consent:* type.

  • The "Bank Data API - Swagger" for the urn:openfinanceuae:account-access-consent:* type.

All of the documents defined above should be used in conjunction with this specification to ensure that all the parties can create and manage consents to resources in a standardized and secure way.\

3. Consent Authorization Sequence Diagram

The diagram below provides a high-level visualization of the redirect journey, also known as authorization_code flow expected to be executed by Data Receivers ( Relying Parties) with Data Transmitters (Open ID Providers) when obtaining an authorization grant from a customer that is willing to share data across institutions :

image-20240419-223048.pngImage Added

4. Design Considerations

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

4.2 Ecosystem Interoperability

A primary goal in reducing the available 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 the 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

...

.

Initially, in 2021, the ecosystem's profile supported two token authentication methods

...

– tls_client_auth and private_key_jwt

...

– and made pushed authorization requests optional. This approach resulted in four possible variations of the same profile for Data Providers

...

. Consequently, Data Receivers had to support all four profiles to achieve interoperability with all Ecosystem Data Providers. This design choice was originally made to facilitate the swift implementation by banks, allowing the ecosystem to go live quickly using some Banks legacy OpenID vendors.

However, from 2021 to 2023, the focus shifted from initial go-live to prioritising interoperability and participant onboarding simplicity. This change in focus has resulted in the Ecosystem eliminating wherever possible any areas in the specification where optionality was given providers implementations. In March 2024, Open Finance Brazil mandated the introduction of Pushed Authorization Requests (PAR) and adopted the use of private_key_jwt as the token authentication mechanism of choice. This change unified the ecosystem under a single profile, simplified and eradicated bank choice in favour of interoperability whilst simultaneously improving ecosystem security.

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:

Topic

What FAPI 2.0 Proposes

What CBUAE FAPI 2.0 Requires

Client Authentication Methods

  • tls_client_auth

  • private_key_jwt

  • private_key_jwt

Method for Sender Constrained Access Tokens

  • MTLS

  • DPoP

  • MTLS

Access Token Life Time

  • Not Specified

  • 10 Minutes

JSW Signing Algorithms

  • PS256

  • ES256

  • EdDSA - Ed25519

  • PS256

Authorization Mechanism

  • Suggests RAR

  • Requires RAR

Message Tracing

  • No longer referenced.

  • Required - x-fapi-* headers for Logging and Tracking Purposes

Client Key Set Management

  • JWKS URI Recommended

  • Required - JWKS Uri

Authorization Non Repudiation

  • If Required - Signed Request Object (FAPI 2.0 Message Signing)

  • Required - Signed Request Object

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

...

:

  • It ensures that non-repudiation of Authorisation Requests is easily achieved

...

  • .

  • 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

...

4.3 Clarification around OFP and LFI Integrations

All documentation relating to the integrations and security layers between the Open Finance Platform (OFP) and the LFI will be provided as part of the OFP Documentation and are not part of the Ecosystem Security Profile, which should be used only for communications that happen directly between the Open ID Providers (Servers) and Open ID Relying Parties (Client)

Communications between the Open Finance Platform and the chosen LFIs will take place using certificates issued by the Trust Framework.