Section

Sub Section

Participant ID

Feedback

Response

API Security

Overview

1

Specification are sufficient

Noted

2

Overview is concise and introduces the topics to be discussed further in the document.

Noted

3

No question at this stage

Noted

4

It is not directly associated with the API itself, but we believe all participants will need to undertake audits. If that’s the case , it will be good to document all of the requirements which are required to get the access.

The application forms and related documentation requests necessary for a TPP to become licensed will be made available.

5

NO, THESE SEEM TO BE ADEQUATE

Noted

6

None

Noted

7

FEEDBACK

-

8

No specific questions or feedback. We are broadly support of the direction of security profile being based on FAPI 2.0 and the OAuth 2.0 Authorization Framework.

Noted

9

1. The liability model must be clearly defined between TPP, the Open Finance Platform, and LFI for aspects such as availability, security, and dispute resolutions. Responsibilities and legal liabilities should be transparent concerning the use of OFP, as well as in cases of data breaches, fraud, and payments.

2. FAPI 2.0 specification is getting mature with its updates. An observation on that, full message payload encryption is not considered in the standard but could be considered for UAE CB Open Finance specification.

3. Did you perform threat modelling on API security model and OFP platform and if yes, what are the outcomes of residual risks and risk ratings after security controls implementation?

4. Ozone API should support the required attributes for LFIs to detect and prevent fraud.

5. Utilizing the existing NPSS/Aani infrastructure (API, networking, etc.) has been the primary objective since the inception of the Open Finance initiative. Could you please clarify to what extent it will be reused?

1. This will be tabled for feedback in round 3 engagement.

2. Payload encryption is not required for FAPI 2.0 as no sensitive data is sent on the Front Channel, meaning that all sensitive data will be communicated via TLS protected endpoints, which already ensures all transfered messages will be encrypted.

3. The API Security is built upon FAPI 2.0, that is, everything that was defined on the FAPI 2.0 CBUAE is compliant with the FAPI 2.0 profile. This means that the Threat Model executed by the OIDF around both FAPI 2.0 and FAPI 1.0 and the Security Considerations can be used for this model, for example - https://arxiv.org/abs/1901.11520

4. The API standards will contain a risk block with metadata supporting LFI transaction risk analysis and fraud detection.

5. The options around this and the feedback have been articulated in some detail in conversations with the LFIs.

10

The API security model seems to be very banking specific, what variations should Insurance Companies expect in the overall security model?

The API Security Profile is data agnostic, that is, there’s no significant difference on the FAPI layer between Banks and Insurance companies.

Section

Sub Section

Participant ID

Feedback

Response

API Security

Security Profile - FAPI

1

FAPI is a comprehensive standard, might be a challenge in implementation.

For Data Providers we expect that the FAPI Layer will be implemented by the API Hub, and hence minimal effort to comply with FAPI is expected for the LFIs

2

Question: Has FAPI 2.0 been finalised as a standard? 

The reduction in optionality is desirable.

Security Profiles Section could do with a model or flow diagram. 

Under consent and management link, I assume this is a placeholder for a future document?

As of 24/04 the FAPI 2.0 WG is on their final definition round and expect to start the process to reach a final standard soon.

We have included a flow diagram on the second version of the Security Profile.

3

FAPI 2.0 is good option and Bank use it for other markets

Noted

4

Will it require additional OpenID certification?  For example, we are already certified by OpenID for FAPI 2.0 for our KSA entity. Do we need to obtain another certification for Lean’s UAE entity? 

The FAPI 2.0 UAE Profile will be different from FAPI 2.0 Vanilla or any other variations and as such, a new certification would be required.

We note that for all LFIs that will use the API Hub for sharing data and managing consents, The OpenID certification will be obtained centrally by the API Hub, so there’s no requirement to issue an individual certification.

For Data Receivers a new will be required.

5

NO

Noted

6

None

Noted

7

Need clarification on what is required on LFI end to ensure & maintain FAPI security profile. There is no clarity on roles & responsibility of what TPP is required to maintain & what LFI has to adhere to & what is the role OFH will pay in the middle. E.g JWKS endpoint who will maintain & who will call?

The FAPI Security Profile will be maintained by the Open Finance Hub, and LFIs will be required to integrate with the API Hub.

JWKS endpoints and certificates will be maintained and issued by the Trust Framework

8

No specific questions or feedback currently.

Noted

9

· Point 12 states "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.". Each consent must have an expiry set to a predefined period e.g. 2 years. This will allow user to reauthenticate and reauthorize the actions by reviewing. To overcome service disruption for its users, TPP could ask for consent renewal early. (As understood from April 17th call, consent refresh will be required which is 1 year at max. Documentation could be updated with clear explanation that there is no consent that will not expire.).

· OAuth2.0 and mTLS should be mandatory for all the parties who want to be part of Open Finance network.

· Implement Private Key JWT Client Authentication where clients signing JWT assertions using their private keys, which are then verified by the authorization server using the corresponding public keys.

· Implement scopes and claims to manage and limit access to specific types of data and services according to the permissions granted to the client.

· Use of PAR (Pushed Authorization Requests) to pre-register authorization requests before the client starts the authorization.

· Implement encrypted tokens (JWE) to ensure that token contents cannot be tampered with or read while in transit or storage.

· Use TLS1.3 where possible.

· Data masking techniques should be used for all sensitive data.

The reasoning behind the refresh_token expiration is based on experiences with both the UK and Brazil.

Both ecosystems started with a limited-time consent ( example: 12 months ) and transitioned to support consent with no expiration. When this change was rolled out, it was only possible for consents to be updated if they were initially created with a refresh_tokens that didn't include an expiration time. All other consents had to be revoked and recreated, something that could have been avoided if they were created with the change we are planning.

10

No specific feedback, we would like to understand variations expected for Insurance Companies?

The API Security Profile is data agnostic, that is, there’s no significant difference on the FAPI profile between Banks and Insurance companies.

The only difference should be expected on the Consent Journey, more precisely on the Authorization Request, that is, the Payload that is sent when the user is redirected to authorize its consent. In this case the authorization details for Insurance should be different from the one from Banking as what the user will approve is slightly different, however, everything else should be similar.

Section

Sub Section

Participant ID

Feedback

Response

API Security

Registration Framework

1

All is good

Noted

2

Reasoning around the selecting OIDC as a solution is sound as issues with DCR did lead to completely avoidable issues in the UK market. 

On the table, principle and reasoning it mentions cross boarder integration.  Is cross boarder integration something that is on the roadmap, or is it something we need to plan for in the nearer future?

How often is it envisioned that a Data Provider will request the list of all Software Statements?

The Registration Framework has been updated to clarify this point :

“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

No question at this stage

Noted

4

Do we impose having a dedicated dev portal for the banks? What security requirements TPPs / OFPs will need to be fulfilled to get the access to LFIs API. 

Dev Portal will be provided as a central service by the OFP.

From a purely technical perspective, TPPs will have to be FAPI 2 compliant RPs.

Additional operational requirements may be placed on TPPs - this is in the regulatory / compliance space and tbc.

5

NO

Noted

6

None

Noted

7

FEEDBACK

-

8

No specific questions or feedback currently.

Noted

9

· In the section "Reasoning around Selecting OIDC Federation as the base for this Profile", the statement "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." might give misunderstanding as TPP needs to be registered by a Federation Admin first, manually.

· In case an LFI doesn’t want to work with a TPP (e.g. TPP is not fully compliant), in current Federation Framework it seems not possible. What will be the solution for these cases?

Your understanding is correct. Once a Federation Administrator includes a TPP they are capable of easily connecting with a Data Provider. The documentation has been updated to clarify that we are talking about “Authorised Data Receivers”.

As for restricting individual TPPs from interacting with LFIs, this is not possible. Once the Regulator and the Open Finance Structure authorize a TPP to operate within the Ecosystem, they are allowed to consume data from any of the providers that support the data that they are authorized to share. If there’s an understanding that the TPP should not be authorized to consume data because of a specific concern, this should be raised to the OF Structure or the Regulator so their Licenses are revoked and they are blocked from communicating with any Data Provider

10

· No specific feedback, we would like to understand variations expected for Insurance Companies?

The API Security Profile is data agnostic, that is, there’s no significant difference on the FAPI profile between Banks and Insurance companies.

The only difference should be expected on the Consent Journey, more precisely on the Authorization Request, that is, the Payload that is sent when the user is redirected to authorize its consent. In this case, the authorization details for Insurance should be different from the ones from Banking as what the user will approve is slightly different, however, everything else should be similar.

Section

Sub Section

Participant ID

Feedback

Response

API Security

Certificate Standard

1

Fine as per standards

Noted

2

Certificate Revocation Process will be included in future versions of this document? 

The Documentation has been updated to clarify that certificates are expected to have a duration period of 13 months.

The Process around creating and revoking certificates will be included in the Trust Framework Operational Guide, which should be released by June/July.

3

No question at this stage

Noted

4

It is advisable to document and standardize the complete certificate lifecycle which means documenting process for renewing certificates, supporting multiple versions of the certificates (there might be a temporal need of using old and new certificate version)

For the Go-Live it’s expected that all supported certificates will follow exactly the profile mentioned on the guide.

Once the Platform is live we also expect to update the documentation to include all the relevant links for the Intermediates and Roots on the PKI.

As for the Certificate Management and Lifecycle this will be included on the Trust Framework Operational Guide.

5

NO

Noted

6

None

Noted

7

What will be connectivity between OFH & LFI  mTLS or via some other mechanism 

To begin with, mtls will be supported to secure the connection between LFIs and OFH.

We intend to introduce dpop as an alternative for LFIs to adopt in the near future (at their option).

The use of MPLS is the subject of a seperate decision paper and tbc.

8

No specific questions or feedback currently.

Noted

9

· 1. When will the link to Open Finance UAE Certificate Practice Statement become available?

· 2. What are the infrastructure and application layer protections for Ozone API Layer, Radium CA infrastructure and certificate management according to NIST SP 800-53?

· 3. What is the FIPS compliancy level for HSM to be used for CA certificates management?

· 4. How Radium platform's privileged accounts and their access will be protected, especially "Federation Administrator"? In case an account is compromised, what are the controls for detection and mitigation?

· 5. Regarding message encryption, the statement is "Message Encryption JWE (JSON Web Encryption) to ensure the confidentiality of messages exchanged between participants". The content to be encrypted is not clear and need to be defined. We would like to have full message payload encryption as it’s a standard used in today's leading payment providers.

· 6. RSA 2048-bit encryption or ECC (Elliptic Curve Cryptography) should be used for certificates.

· 7. Certificate pinning will help here to prevent MITM attacks or we can also push for mandatory usage for mTLS usage.

· 8. Certificate rotation and revocation should be in place.

1. The Open Finance CPS will be provided by September, a few weeks before the Trust Framework is fully live.

2. The Trust Framework Infrastructure (Raidiam) complies with ISO27001 standards. The Certification document as well as other clarifications around our Infosec compliance can be obtained on http://trust.raidiam.com/

3. Private Keys stored by the Trust Framework are set on an HSM with a FIPS 140-2 level 3 certification.

4. Access to the Trust Framework, regardless of whether the user is a Global Administrator or a Regular User will require password plus a TOTP second factor authenticator ( Example Google Authenticator ). If an account is compromised other existing administrators or Raidiam Service Team are capable of revoking the access of this user. Additionally, the Federation Administrator Role will be limited to the least possible amount of individuals.

5. FAPI 2.0 mandates mTLS, which requires all API calls to be sent via TLS, ensuring end to end encryption of all messages. There’s perceived additional security benefit to use JWE together with mTLS.

6. All Leaf Keys used on Open Finance will have a length of 2048 bits as per the Certificate Profile. For TLS 1.2 the following ciphers should be used as per the FAPI 2.0 profile
   TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
   TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
   TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
   TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384

7. mTLS is mandatory as well as Certificate Bound Access Tokens.

8. Certificates will have an expiration period of 13 months, and we expect all certificates to be rotated at least a year.

10

No specific feedback, we would like to understand variations expected for Insurance Companies?

Noted

Section

Sub Section

Participant ID

Feedback

Response

User Experience Principle

General

1

User experience is essential for so many elements:

1. To keep it simple

2. Improve accessibility

3. To be transparent

4. Maintain consistency

5. Provide logical navigation

6. Use clear language

7. Support your customers

8. Improving user experience with app-to-app redirection

Noted

2

The current UX principles are fine and clearly set expectations on how to design a friendly and informative transaction journey for a user while using Open finance services.

But to increase the overall awareness, and trust in Open Finance among the users TPP/LFIs need to establish an information repository or a help centre for their customers (can be bundled with the consent management page) where users can get access to:

1. FAQs on Open finance related processes

2. Best practices to identify and avoid fraudulent transactions

3. Redressal mechanisms in case of any dispute/fraud or any other unforeseen issue with appropriate email ids and phone numbers to lodge complaints with the concerned TPP/LFI (inline with the dispute mgmt. procedures enforced for OF)

4. Information regarding data usage and retention policies if the consent is revoked

And this information page can also be templatized/standardized across TPP/LFI so the user is comfortable seeing similar information across participant interfaces, and this will help generate more trust in the platform and clampdown on misinformation by bad actors.

A website will be made available from the Open Finance Company when established which will contain this type of content.

3

No question at this stage

Noted

4

While it’s good to have a good text description as it’s in point no 3. It would be useful for participants to see sample designs which should be followed by TPPs, OFPs, LFIs.

While the expectations are clear from the MUST and SHOULD statements. There is too much subjectivity in the language as proposed. The standard should outline what specific information must be presented to users, and where applicable the correct terminology to use to describe that information - terms like ‘straightforward and easy to use interface’ leave a large amount of gray area both to TPPs and LFIs which can become somewhat unenforceable.

Sample designs with CBUAE branding will be available. Time lines to be confirmed.

Section 3 has a detailed textual description of the main user experience principles that the Standard follows and that participants must/should follow when designing their user experience. Samples of the designs are shonw in the wireframes in the Banking Service Initiation and Data Sharing pages.

The page in section 3 only documents the principles at a high level. The Service Initiation and Data Sharing pages in the Banking section provides the exact information that must be dsiplayed to the users by TPPs and LFI during each differct consent scenario. Similarly, it provides the correct teminology and language to use to each user screen.

5

NO

Noted

6

None

Noted

7

Provide the sample “approved” content of the Consent information page. For example, the requirements for the Transparency, Trust and Sense of Control are very robust in terms of information provided – but then mentions as unhelpful element “Where there are fewer screens but a significant amount of text on the screen”

Sample “approved” content is included in the wireframes in the Banking Service Initiation and Data Sharing pages.

8

Principles should be exactly that – principles, not regulations. On the basis that the ‘Use Experience Principles’ are provided and governed as ‘principles’ (and not prescriptive mandates), we are broadly in line with the proposal.

However, LFI’s as regulated entities are obliged to do whatever they deem necessary to protect their clients and themselves against risk and fraud and the principles MUST be broad enough to enable LFIs to carry out this duty. An example may be additional step-ups in authentication (based on the LFIs own risk assessment) to validate the authenticity of a consent request. In some cases, this may add additional friction to the flow, but this would be by design, in order to raise the threshold required to appropriately validate the user/request. LFI’s MUST have discretion to authenticate users/consent requests, as they deem appropriate, and consistent with, the measures they apply to their own channels.

We operate in a multi-lingual market; however nothing is covered in the principles with regards to language preferences. We should consider a language parameter in the consent interaction, to enable English or Arabic language preferences to be handed from the TPP to the LFI, to ensure a seamless experience. It is possible that users may have an Arabic language preference on their LFI channel, but be coming from an English TPP site/service (or vice versa) – we need to consider how to handle such scenarios (e.g. should the session override the existing channel language preference).

Noted

The key principle here is that of parity between direct and API channels - there should be no additional friction carte blanche for all transactions initiated through API channels.

LFIs will have the flexibility to apply additional authentication where appropriate based on risk factors. LFIs will be measured on successful authentication rates across channels and will need to demonstrate that risk measures are commensurate and not barriers.

The multilingual aspect is noted. LFIs could utilise the same measures that they utilise on their direct channels (e.g. http accept-language headers that are set by browsers) to provide an indication of preferred language

9

We suggest the summary information step for vulnerable users should be provided to all users for the first time they use open finance.

· Do the User Experience Principles ensure accessibility for users with disabilities or special needs?

The summary information step is specifically designed for usage by vulnerable users, who may not be in a position to get informed appropriately for the use of Open Finance. For standard users, the information and education about Open Finance must be performed by the ecosystem participants.

No, the current user experience example wireframes do not cater for users with disabilities or special needs. LFIs and TPPs are expected to adapt their UX to accommodate for these users.

10

1. For Informed decision making, is AI expected to be play a big part in the open finance platform?

2. Is Single Sign on Integrations expected between TPPs and LFIs? Will this be facilitated by the CB UAE or will integrations need to be done individually with each TPP?

3. Every LFI and TPP have their own CX/UX Principles, how does CB UAE aim to consolidate this across all LFI or TPP on the Open Finance Platform?

4. This is very banking specific and what can Insurance companies expect here?

1. No use of AI is planned in the current release. On the Ozone roadmap, we are reviewing the use of AI to deliver a natural language search on developer portals and for querying report data. This will not result in additional work for LFIs.

2. Single Sign On is a capability provided in form of the Centralised Authentication and Authorisation https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1draft2/pages/54624286

This is an option for LFIs that do not have mobile channels or that are not able to offer the mobile authentication experience.

3. The service CX/UX will be monitored and any corrections managed through CBUAE Supervision regime where necessary. Certain screens will be mandated to be in a standardized format, for particular parts of the journey.

4. A section specific to insurance is included in Standards V0.1 Draft-2.

Section

Sub Section

Participant ID

Feedback

Response

Consent Setup

General

1

It is recommended to have in the consent for audit and compliance matters.

On the other hand, For any payment, purpose is mandatory for initiation by the LFIs, which will be part of the payment initiation request.

So, shall TPP collect those mandatory from the user and pass it in the payment request along with others parameters to LFI through OFP?

Alternatively, when user authenticate the payment request in LFI app, LFI to display the additional fields needed and then execute the request (example; in single payment request)?

Having said that for consent standards for TPPs for look and feel and user journey through its app.

The purpose for the consent if included will be sent by the TPP. This purpose is around the kind of use case that the Open Finance request is made for example, Account Aggregation, Personal Finance Manager,Tax Filing, Wallet Topup, P2P etc

This is not to be mixed with the purpose which the user is asked to enter by the LFI for example in an international payments etc. That purpose which is specific to use cases like international payments or SME payments will also be sent by the TPP as part of the consent.

2

Having a predefined list of purpose statements is a good idea to codify the consent structure,

For payment transactions we can create a multi-level classification, level 1 will indicate participants in the txn and flow of funds (left to right) (example given below)

1. Customer to Business

2. Customer to Govt.

3. Business to Business

4. Business to Govt.

5. Govt to Customer

6. Govt. to Business

7. Business to Customer

On Level 2 will be single payment or multiple

And level 3 will have a brief description explain the context (this can be a free text field to be entered by TPP)

The way the consent table is designed in the multi payment section of the shared document is a good example.

But for data sharing request it might be tough because we will have to think an exhaustive list of business use case and codify them, and still make a provision to accommodate new use cases in future.

Question: What are rules regarding Consent request expiry (authorization request expiry)? consider a scenario where a consent request is triggered and customer has not approved it, till when the consent request will remain valid.

Question: This was raised in the workshop as well, in case of accounts that require multi-level authorization (joint a/c or business a/c), what happens if the authorization request expiry is reached but all consents have not been granted?

Question: In case of multi-level authentication, how does LFI keep the TPP informed of consent progress, just one time update of consent granted when all approvals are in place, or approval by approval communication to TPP (ideally this should not be recommended because this is a risk revealing a client’s approval matrix to the TPP)

Agree that the purpose needs to be a codified list and it will be on the lines of

Account Aggregation, Personal Finance Manager,Tax Filing, Wallet Topup, P2P etc

We will consider your input on also indicating the participants as part of the coded list.

Re: Authorization Request Expiry: The consent authorization request expiry is defined by the TPP as in https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1draft2/pages/52528830/Common+Rules+and+Guidelines#8.-Authorization-Time-Window

Re: Multi Authorization

The consent will move to a Rejected state as explained in https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1draft2/pages/56885249/Consent+Setup#4.-Consent-States

Please refer to the section which details the flow for multi authorization

https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1draft2/pages/52528830/Common+Rules+and+Guidelines#18.-Multi-User-Authorization-Flow

Re: Notifications on Multi Authorization

Please refer to the following two sections which details on how the TPP is notified. The TPP will receive the list of pending authorizations.

https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1draft2/pages/52528830/Common+Rules+and+Guidelines#CRG-17.4-Multi-User-Authorization-Flow-Notifications and

https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1draft2/pages/52528830/Common+Rules+and+Guidelines#18.-Multi-User-Authorization-Flow