Versions Compared

Old Version 32

changes.mady.by.user Former user

Saved on

compared with

New Version 33

changes.mady.by.user Former user

Saved on

Key

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

...

  • The certificate is technically correct and is not expired.

  • The certificate is qualified. 

  • The PSD2 information in the certificate such as the PSD2 roles, Authorisation Number, etc. match with the API being invoked.

  • The certificate is not revoked using Certificate Revocation Lists (CRL) or Online Certificate Status Protocol (OCSP) validations. For more information, see the certificate revocation validation section.

Qualified Certificate for Electronic Seal (QsealC)


Note

The Qualified Certificates for Electronic Seal (QsealC) feature is currently WIP.

QSealC provides evidence with a legal assumption of authenticity and integrity of a transaction. QsealC ensures the application layer security to protect the data or messages from potential attackers during or after the communication. 

  • A TPP signs the payload of an API invocation request using the private key of its QSealC and sends the signed request along with the QSealC. 

  • The ASPSP extracts the QSealC from the request header and verifies whether the organizational identifier of the QWAC matches with the organizational identifier specified in the QSealC. 

  • The ASPSP performs the certificate revocation validation using OCSP and CRL information included in the QSealC.

  • Once the certificate validation is successful, the ASPSP performs signature validation using the public key contained in the QSealC.

Certificate revocation validation

Multiexcerpt
MultiExcerptNameInfocertificateRevocationValidation

A certificate is issued by a trusted organization under European Union (EU) legislation, commonly known as a Certificate Authority (CA). It is called a Trust Service Provider (TSP). These certificates are expected to be in use for their entire validity period. However, certain circumstances may cause a certificate to become invalid prior to the expiration of the validity period. For example, a compromise or suspected compromise of the corresponding private key may cause a certificate to become invalid prior to the expiration.  

The following diagram shows how the TSP revokes the certificate:

For qualified certificates (QWACs and QSealCs), a revocation request can originate from the National Competent Authority, which has authorised or registered the PSP. The TSP revokes the certificate based on a verifiably authentic revocation request. 

Under such circumstances, the issuing CA needs to revoke the certificate prior to the scheduled expiry date so that the certificate would no longer be trusted. There are two protocols to check whether a given certificate is revoked by its issuer. 

  • Certificate Revocation List (CRL) is a list of digital certificates that have been revoked by the issuing CA.

  • Online Certificate Status Protocol(OCSP) is an internet protocol used for obtaining the revocation status of a digital certificate based on the certificate serial number. The OCSP validation is faster compared to the CRL validation

In WSO2 Open Banking, the revocation status of a certificate is verified primarily using the OCSP validation. If the OCSP validation is unsuccessful, the revocation status is verified using the CRL information. The certificate is rejected if none of these protocols is successful or if the required revocation information is not found on the certificate.

Enable certificate revocation validation

Multiexcerpt
MultiExcerptNameintroConfigsEnablingCertRevocationValidation

This section explains how to enable the certificate revocation validation feature. Make sure that the following configurations are added in the relevant locations.



Multiexcerpt
MultiExcerptNameconfigsCertificateRevocationValidation

  • The mtlscertvalidator module needs to be engaged under the Globally Engaged Modules section in the <WSO2_OB_APIM_HOME>repository/conf/axis2/axis2.xml file.

    xml

  • <CertificateManagement> configurations in the <WSO2_OB_APIM_HOME>repository/conf/finance/open-banking.xml under the server root element.

    xml

    An improvement to the certificate revocation validation is sent via WUM to extend the revocation validation. This is effective from September 3, 2019 (09-03-2019). Apply the following configurations in order to update the solution.

    • Add the following configurations under the <CertificateManagement> element in the <WSO2_OB_APIM_HOME>repository/conf/finance/open-banking.xml file.

      xml
Note

See eIDAS Implementation for PSD2 Compliance, for more information.

MTLS bound access token 

According to the OAuth 2.0 Authorisation Framework, TPPs can obtain delegated access to protected resources. This is implemented by binding the user access token to the MTLS certificate.

In order to bind the MTLS certificate of the TPP that is sent in the requests to the user access token, follow the instructions given below:

Note

Before following the instructions given below, configure the client certificate header name in <WSO2_OB_KM_HOME>/repository/conf/finance/open-banking.xml as described here.


  1. Locate the <WSO2_OB_KM_HOME>/repository/conf/identity/identity.xml file and update as follows:

    1. Change the GrantTypeHandlerImplClass of the authorization code grant type as follows:

      Code Block
      languagexml
      <SupportedGrantType>
	<GrantTypeName>authorization_code</GrantTypeName>
    <GrantTypeHandlerImplClass>com.wso2.finance.open.banking.identity.extensions.grant.type.handlers.MTLSTokenBindingAuthorizationCodeGrantHandler</GrantTypeHandlerImplClass>
</SupportedGrantType>

    2. Change the GrantTypeHandlerImplClass of the refresh token grant type as follows:

      Code Block
      languagexml
      <SupportedGrantType><GrantTypeName>refresh_token</GrantTypeName> 
<GrantTypeHandlerImplClass>com.wso2.finance.open.banking.identity.extensions.grant.type.handlers.MTLSTokenBindingRefreshGrantHandler</GrantTypeHandlerImplClass>
</SupportedGrantType>

    3. Add the following event listeners under <EventListeners> in <WSO2_OB_KM_HOME>/repository/conf/identity/identity.xml:

      Code Block
      languagexml
      <EventListener enable="true" name="com.wso2.finance.open.banking.identity.extensions.introspection.OBIntrospectionResponseInterceptor" orderId="27" type="org.wso2.carbon.identity.core.handler.AbstractIdentityHandler"/>
 
<EventListener enable="true" name="com.wso2.finance.open.banking.identity.extensions.introspection.OBIntrospectionDataProvider" orderId="28" type="org.wso2.carbon.identity.core.handler.AbstractIdentityHandler"/>

    4. Add the following configs under <Server> element:

      Code Block
      languagexml
      <Introspection>
    <EnableDataProviders>true</EnableDataProviders>
</Introspection>

  2. Whitelist  the <ScopeWhitelist> property inside the <OAuthConfigurations> section in <WSO2_OB_KM_HOME>/repository/conf/api-manager.xml  as follows:

    Code Block
    languagexml
    <Scope>^x5t.*</Scope>