Page Comparison

• mTLS - Mutual TLS) participants' applications

• .

• Message Signature

• – JSON Web Signature (JWS) – for applications to ensure authenticity and non-repudiation of messages between participants

• .

• Message Encryption

• – JSON Web Encryption (JWE) – to ensure the confidentiality of messages exchanged between participants;

• Authenticate Organisation in the Open Finance Trust Framework APIs and the other Central Infrastructure provided APIs

• .

• Enable back-channel communications between the Open Finance Hub (OFH) and participants.

2. Introduction

The Open Finance UAE ecosystem makes use of chains of certificates and the TLS protocol to guarantee the confidentiality, authentication and integrity of the communication channel used by the APIs of the participating organisations, as well as the customers of each of the participants.

The certificates used by Open Finance UAE are also required to authenticate applications through the private_key_jwt

OAuth client authentication method. in addition to being used to perform the payload signature using JWS. Another important attribution of certificates is to present a secure channel to the end user in the act of authentication and use of services provided by the participating organisations.

3. Certificate Format

All the Certificates used on the Open Finance UAE ecosystem must be issued by the Ecosystem Trust Framework

.

The certificate issuing and revocation processes

, the practices,

availability,

and values can be found on the Open Finance UAE Certificate Practice Statement < Include Link Once Issued >.

3.1 Certificate Types

The Open Finance UAE Ecosystem supports four types of certificates, differentiated by their use cases: two are designed for digital signatures and the other two are for mutual TLS (mTLS) authentication.

3.1.1 Server Certificates:

• Server Transport Certificate: This certificate is to be used by servers when securing the mTLS channel for API communications, ensuring that data exchange between client applications and the server is encrypted and mutually authenticated.

  • On the Trust Framework Directory, this Certificate is denoted as

• • OPF UAE SERVER TRANSPORT

• • and is managed at the

• • Organization Certificates level.

  • On the Transport Trust Framework Keystores, they have their

• • use set as

• • enc.

• Server Signature Certificate: Utilized to sign message payloads, this certificate guarantees the non-repudiation of server-issued payloads. By employing digital signatures, it ensures the authenticity and integrity of the messages, preventing any dispute over their origin and content.

  • On the Trust Framework Directory, this Certificate is denoted as

• • OPF UAE SERVER SIGNING

• • and is managed at the

• • Organization Certificates level.

  • On the Application Trust Framework Keystores, they have their

• • use set as

• • sig.

• Server Encryption Certificate: Employed for the encryption of message contents using JSON Web Encryption (JWE), ensuring confidentiality of messages sent by Servers.

  • On the Trust Framework Directory, this Certificate is denoted as

• • OPF UAE SERVER ENCRYPTION

• • and is managed at the

• • Organization Certificates level.

  • On the Application Trust Framework Keystores, they have their

• • use set as

• • enc.

3.2.2 Client Certificates:

• Client Transport Certificate: Similar to its server counterpart, this certificate is essential for securing the mTLS channel for API communications from the client side. It assures that the exchange between the server and client applications is encrypted and mutually authenticated.

  • On the Trust Framework Directory, this Certificate is denoted as

• • OPF UAE CLIENT TRANSPORT

• • and is managed at the Software Statement Certificates level.

  • On the Transport Trust Framework Keystores, they have their

• • use set as

• • enc.

• Client Signature Certificate: This certificate serves two primary functions. It enables secure application authentication using the private_key_jwt method, thus verifying the client's identity. Additionally, it allows for the signing of message payloads, ensuring the non-repudiation of client-issued payloads.

  • On the Trust Framework Directory, this Certificate is denoted as

• • OPF UAE CLIENT SIGNING

• • and is managed at the Software Statement Certificates level.

  • On the Application Trust Framework Keystores, they have their

• • use set as

• • sig.

• Client Encryption Certificate: Employed for the encryption of message contents using JSON Web Encryption (JWE), ensuring confidentiality of messages sent by Clients.

  • On the Trust Framework Directory, this Certificate is denoted as

• • OPF UAE CLIENT ENCRYPTION

• • and is managed at the Software Statement Certificates level.

  • On the Application Trust Framework Keystores, they have their

• • use set as

• • enc.

3.2 Certificate Validity Period

All Certificates issued by the Open Finance Trust Framework have a validity period of 13 months.

Certificates should be replaced at least one month before the end of their validity period to ensure continuity of services.

4. Certificate Subject DN

4.1 Server Certificates

The Following Fields will be included on

all of the

SERVER CERTIFICATES certificate subject distinguished name:

• organizationalUnitName (OID 2.5.4.11): Organisation ID (UUID) as defined on the Trust Framework

• organizationName (OID 2.5.4.10): Organisation Legal Name as defined on the Trust Framework

• countryName (OID 2.5.4.6): Country of the Organisation as defined on the Trust Framework

4.1.1 Example SubjectDN for

Server Certificate :

An Organisation Raidiam, registered on the Trust Framework with Code : 94271194-ad90-4c39-b564-a080e7cb0bf1 and legally registered on the UK Companies House, would have a certificate with the following subject_dn:

OU=94271194-ad90-4c39-b564-a080e7cb0bf1,O=RAIDIAM SERVICES LIMITED,C=UK

4.2 Client Certificates

The Following Fields will be included on

all of the

CLIENT CERTIFICATES certificate subject distinguished name:

• commonName (OID 2.5.4.3): Software Statement ID (UUID) as defined on the Trust Framework

• organizationalUnitName (OID 2.5.4.11): Organisation ID (UUID) as defined on the Trust Framework

• organizationName (OID 2.5.4.10): Organisation Legal Name as defined on the Trust Framework

• countryName (OID 2.5.4.6): Country of the Organisation as defined on the Trust Framework

Besides the mandatory Subject DN fields listed above, the Client Transport Certificate can also incorporate the X509v3 Subject Alternative Name field. To include these fields, they must be added to the CSR before it is uploaded to the Trust Framework.

4.2.1 Example SubjectDN for

Client Certificate :

A Software Statement with Code : 931d3825-d7af-44d6-a59c-cff1ebb1131, registered on the Same Raidiam organisation defined above, would have a client certificate with the following subject_dn:

CN=931d3825-d7af-44d6-a59c-cff1ebb1131a,OU=94271194-ad90-4c39-b564-a080e7cb0bf1,O=RAIDIAM SERVICES LIMITED,C=UK

5. Root C.A Issuers

5.1 Production Environment

The Production Trust Framework will use the following issuers to issue certificates.

Distinguished Name : C=AE, O=Open Finance UAE, OU=Open Finance UAE Production Trust Framework, CN= Open Finance UAE Production Root CA - G1

< Include Link to Intermediate CA JWKS once issued >.

< Include Link to intermediate CA OCSP responder and CRL list >

The following root certificate authority will be used on the Trust Framework :

Distinguished Name : C=AE, O=Open Finance UAE, OU=Open Finance UAE Production Trust Framework, CN= Open Finance UAE Production Issuing CA - G1

< Include Link to Root CA JWKS once issued >.

All intermediate and root issuers will use the following algorithms:

• Key Algorithms: RSA 4096 bits ;

• Message Digest: SHA 256 bits

5.2 Sandbox Environment

The Sandbox Trust Framework will use the following issuers to issue certificates.

Distinguished Name : C=AE, O=Open Finance UAE, OU=Open Finance UAE Sandbox Trust Framework, CN= Open Finance UAE Sandbox Root CA - G1

< Include Link to Intermediate CA JWKS once issued >.

< Include Link to intermediate CA OCSP responder and CRL list >

The following root certificate authority will be used on the Trust Framework :

Distinguished Name : C=AE, O=Open Finance UAE, OU=Open Finance UAE Sandbox Trust Framework, CN= Open Finance UAE Sandbox Issuing CA - G1

< Include Link to Root CA JWKS once issued >.

All intermediate and root issuers will use the following algorithms:

• Key Algorithms: RSA 4096 bits ;

• Message Digest: SHA 256 bits

6. Trust Framework Certificate Generation

Certificates will be issued directly within the Trust Framework (TF) application. This process involves submitting a Certificate Signing Request (CSR) in the standard PKCS#10 format, which will then be validated by the TF Registration Authority (RA). Upon validation, the CSR will be signed by the TF Certificate Authority (CA), and the resulting certificate will be accessible via the TF Application and its keystores.

The TF RA will compare the CSR fields against the corresponding information registered in the Trust Framework for the organization. The table below outlines the Directory API values that will be matched with the CSR:

6.1 Algorithms

All the leaf/end-entity certificates issued by the Trust Framework will have the following characteristics:

• Key Algorithms: RSA 2048 bits;

• Message Digest: SHA 256 bits

6.2 Key Usage and Extended Key Usage Attributes :

The following values are to be expected on the four supported certificate types.

7. Cache and Validation Policies

7.1 Certificate Status Verification

7.1.1 mTLS Certificate Revocation Status Validation:

Certificates used for mTLS must be validated via OCSP or CRL without caching the status for more than 15 minutes.

7.1.2 Signature Public Key Validation

Public Keys used for payload signature validation must also not be cached for over 15 minutes, necessitating validation within key stores at least every 15 minutes.