Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 6 Next »

OBIE approach and clarifications regarding adjustment period

Problem statement

On 5 February 2020, the FCA updated its website in relation application of Strong Customer Authentication. This update included an additional section providing further clarity on the use of eIDAS certificates at the end of the adjustment period, which concludes on 14 March 2020.

Following this adjustment period, TPPs must identify themselves to ASPSPs using an eIDAS certificate. ASPSPs must be able to accept an eIDAS certificate from the TPP directly. Additionally, TPPs may use an alternative identification certificate issued by an API Programme, e.g. OBIE, provided that those TPPs have registered their eIDAS certificate with that API Programme and the API programme continues to perform checks of the status of the eIDAS certificate.

OBIE has received requests on the potential impacts on the OBIE Standard and OBIE Directory as some participants are still uncertain how this will affect them after the conclusion of the adjustment period.

Recommendations

OBIE has considered the impact on the use of the OBIE Directory and OBIE Standard for participants in the OBIE ecosystem following the adjustment period. The recommendations below are intended to assist participants to ensure that they understand the relevant impacts.

Ultimately, it is up to each participant to ensure that they meet their applicable regulatory requirements and ensure they raise any concerns in this regard directly with the FCA or their internal legal teams, as appropriate.

Use of certificates for purposes of identification

Each ASPSP must be able to accept a connection from a TPP who identifies themselves via an eIDAS certificate. The EBA Opinion on the use of eIDAS certificate under PSD2 contemplates that it is the choice of the ASPSP to determine whether it wishes to support a QWAC or QSEAL for the purposes of identification. For ASPSPs implementing the OBIE Standard, it is expected that ASPSPs will be supporting only QWACs for the purposes of identification.

The OBIE Standard requires the use of MATLS for secure communication. The act of establishing a MATLS connection is an act of identification, as it requires the ASPSP and TPP to identify each other.

An ASPSP does not need to identify themselves using an eIDAS certificate, so could use any appropriate certificate to establish a MATLS connection.

ASPSPs and TPPs also may agree to allow the TPP to use OBIE issued certificates for this purpose. As contemplated in the FCA publication, ASPSPs can enable this alternative identification certificate to a TPP that has enrolled with the API programme, such as OBIE, using its eIDAS certificate to identify itself.  The API provider will then continue to check  the validity of that eIDAS certificate on behalf of the ASPSP.

Regardless, each ASPSP must also be able to accept a valid eIDAS QWAC from a TPP for every MATLS connection.

Message signing

Message signing in itself is not considered an act of identification. 

The OBIE Standard and FAPI profile make use of message signing in a number of scenarios (e.g. to facilitate non-repudiation for payment initiation). ASPSPs and TPPs can use an eIDAS QSealC, any other signing certificate, or signing keys, to sign messages. The OBIE Directory can be used by ASPSPs and TPPs to facilitate any of these methods.

Use of software statements to connect

As defined in the OBIE standard (DCR specification), an ASPSP can require a TPP to generate a software statement as part of the connection process to access their API. An ASPSP can engage a service (e.g. the OBIE Directory) to facilitate such connection; however the ASPSP must make it clear to the TPP that this is the ASPSP’s part of their connection process.

After 14 March 2020, TPPs will be required to upload a valid eIDAS certificate to the OBIE Directory in order to create any new software statements.

Further questions

Should you have any questions regarding this the FCA’s communication, we would encourage you to contact the FCA direct. 

If you have any further specific questions regarding implementation of the OBIE Standard or use of the OBIE Directory post 14 March 2020, please contact us direct via the OB Service Desk.

eIDAS (ETSI) certificates

What is the process for UK Banks to transition to eIDAS?

This is one for the ASPSPs to answer, but at a high level, ASPSPs have implemented validation for eIDAS trust chains in their gateways.  eIDAS is challenging as it would need to include root certificates from all ASPSPs. Many ASPSPs are keen to continue using an OBIE root certificate in their Trust Store so they do not have to do the above. In which case, the FCA has stated that an ASPSP may request that a TPP registers with an API programme, e.g. OBIE, using their eIDAS certificate and then use OBIE eIDAS-like certificates to register and transact with the ASPSP. However, the expectation is that ASPSPs must be able to accept eIDAS certificates of a TPP.


Will OBIE offer services to validate QSEALs at the network layer?

Currently, ASPSPs can check via the OCSP endpoint (or via CRL if OCSP is unavailable) plus the certificate is checked every 10 mins. Alternatively, ASPSPs can hit the OB Directory certificate validation endpoint. For details on how to use that endpoint see the DIR-API swagger specification linked to from Directory 2.0 Technical Overview v1.3 and Technical Directory Services.


Is a TPP allowed to include the certificate in the header?

Yes.


What are the technical possibilities for enrolling with an EU eIDAS certificate – MTLS doesn’t allow certificates not in the Trust Store. What options are provided by OBIE?

FAPI allows for the use of QSeals, so the OBIE will allow DCR using QWACs or QSeals.  ASPSPs could do the same and this is an active topic in TDA. But OBIE cannot mandate that ASPSPs do this. Also, OBIE ingests roots and issuing certificates from the national Trust Lists and makes them available to ASPSPs via a JKS file to facilitate their Trust Store set up / maintenance.


When ASPSPs authorise TPPs using eIDAS, does this occur only during registration or are there other validations as well?

ASPSPs do not authorise TPPs. NCAs authorise TPPs. eDIAS certificates identify the TPP and  will also contain their relevant PSD2 roles and authorisation number. It is ultimately for each ASPSP to determine any additional validation that needs to take place, noting that some eIDAS certificates will only contain PSD2 authorisations based on a snapshot at the time of issuing the certificate, as well as, relevant regulatory considerations.


Is there going to be an updated Security Profile which takes into account eIDAS checks?

ASPSPs are required to be compliant with FAPI. We are not aware of a need to update it in this regard, nor of any plans.


Is there any documentation on how/where exactly in the current process we should be using eIDAS certificates in the future?

Yes please refer to the Usage Guidelines and the Swagger API documentation. See Technical Directory Services for links.


If we are using certificates to authenticate with ASPSPs, do we still need to register with them?

Yes, you still need a client to onboard.

OB ETSI like certificates

What TPP feedback is there on obtaining an eIDAS certificate?

  1. Feedback from an AISP in mid 2019 – "It took 9 months. We had to fly the QTSP CEO to Portugal and hire a Portuguese speaker. We had to correct their forms. QTSPs are not ready for this."
  2. Mainland EU countries are not accepting EU certificates from other EU countries.
  3. Some QTSPs do not have an EU-issuing country.

Obtaining an eIDAS Certificate


Can I use a test QWAC/QSEAL with any ASPSP?

Yes, orovided thar the ASPSP has implemented eIDAS into their Test Facility and Production Interface. You can use Production eIDAS certs in the OBIE Directory Sandbox. However, you cannot use the Certificate Validation service in the OBIE Directory Sandbox to validate Test eIDAS certificates and you cannot upload these in the OBIE Directory Sandbox . 


OBIE legacy certificates


Where can I find the Open Banking root and issuing certificates?

They can be downloaded from this confluence page in the Collaboration space:   /wiki/spaces/OBT/pages/1144294132


What is the Organization for the Directory transport certificates?

The Organization for the chain are:-

  • root certificate: OpenBanking
  • issuing certificate: OpenBanking
  • transport certificate (leaf): OpenBanking


What is the organization unit (OU) for the Directory transport certificates?

The OUs for the chain are:-

  • root certificate: does not have an OU.
  • issuing certificate: does not have an OU.
  • transport certificate (leaf): Open Banking Directory.


What are the Common Name (CN) for the OBIE domains to perform the TLS MA handshake?

For MATLS for OBIE Directory services, the Directory presents a legacy OBIE transport certificate. 

The common names for the chain are:-

  • root certificate: OpenBanking Root CA
  • issuing certificate: OpenBanking Issuing CA respectively
  • transport certificate (leaf): matls  


What is the Common Name (CN) for the OBIE legacy signing certificate?

The common name = signing.

CSR validation

What CSR (certificate signing request) validation is undertaken?

This depends on the certificate type. For OB legacy transport and signing certs we check that:-

  • The incoming CSR contains an RSA public key of 2048 bits.
  • The Distinguished name contains the org id in OU and software statement id in CN.
  • If the CSR contains a Subject Alternate Name that the requesting org is an ASPSP.

For OBWAC/OBSEAL we check that:-

  • The incoming CSR contains an RSA public key of 2048 bits.
  • The Distinguished name contains the ETSI organizationIdentifier in its own field, and OB org ID is in the CN.
  • The QC Statement indicates that the type of cert (WAC/SEAL) is consistent with the requested type.
  • The QC Statement does not claim any PSD2 roles that the organisation does not have.

Both categories will also do simple checks, e.g., all expected name components are present, not duplicated, in the right order, etc. etc​.

QTSP certificates and services


Do we have an eIDAS QTSP in the UK yet? Can you recommend a QTSP in the UK? 

There is no UK QTSP yet. We cannot recommend a QTSP.


Should we be checking the validity of certificates against a QTSP, or will revoked QTSP certificates be available within the Open Banking certificate revocation list?

There will  always be a gap in the revocation of a certificate by a QTSP and OBIE becoming aware. eIDAS certificates uploaded by participants to the OBIE are checked every 10 minutes and moved to the revoked store if revoked. As they are not OBIE CA certificates they will not appear in the OBIE CA's CRL (certificate revocation list).

JKS stores in S3

Where can we find the QTSP JKS files in Sandbox?

 QSealC

https://obdqtspkeystore.openbankingtest.org.uk/artefacts/QTSP/EU/latest/qseal/data.jks

QWAC

https://obdqtspkeystore.openbankingtest.org.uk/artefacts/QTSP/EU/latest/qwac/data.jks


Where can we find the QTSP JKS files in Production?

QSealC

https://obdqtspkeystore.openbanking.org.uk/artefacts/QTSP/EU/latest/qseal/data.jks

QWAC

https://obdqtspkeystore.openbanking.org.uk/artefacts/QTSP/EU/latest/qwac/data.jks


SCIM QTSP resource/endpoint

How do we filter/query the QTSP endpoint?

This is described in the SCIM Swagger specification. Linked to from Appendix A in the Directory 2.0 Technical Overview Draft 1.2 (about to be updated to 1.3).

Root and intermediate certificates

If a TPP submits an eIDAS certificate to an ASPSP and the ASPSP doesn’t have the QTSP root certificate in the Trust Store, what happens?

It will not work. You cannot transact.


Where can we get the endpoint for root certificates for QTSPs?

This is specified in the SCIM swagger specification in GitHub. Have a look at Directory 2.0 Technical Overview Draft 1.2 (about to be updated to 1.3), and you will see a link to GitHub in Appendix A (this includes root and intermediary certificate info).


Why can't I find a QTSP root or intermediate certificate in the SCIM QTSP resource?

If the QTSP does not publish its root or intermediate certificates on the national list, we have no way of obtaining them.  The national supervisory body that manages the national Trust List may have a policy of not publishing root certificates.

The root certificate may be a cross certificate, i.e., it might be used to sign qualified issuing certificates (intermediate certs) and non-qualified issuing certificates, e.g., SSL certificates. 


How can I find a QTSP certificate chain, root or intermediate certificate in the SCIM QTSP resource?

1) Have a look at the client certificate's Issuer name and then do a search on the X509SubjectName attribute of the OBQualifiedTrustServiceProviders SCIM resource.
2) The result of 1) should be a list of certificates, most likely intermediate certs, but just to make sure, compare Subject name and Issuer name inside each of those certs to see if they are the same.
3) If they are, you have found a root certificate.
4) If they are different, you have an intermediate certificate in which case you need to take Issuer name for each intermediate certificate and search on the X509SubjectName attribute of the OBQualifiedTrustServiceProviders SCIM resource.
5) If the certificates returned have identical Subject name and Issuer name then they are root certificates if they are not... go back to step 4).

Validation checks

Does an ASPSP do their own QTSP checks?

ASPSPs can either check with the QTSP themselves or use OBIE Directory services.

Accessing the Directory Frontend Interface (DFI)

There are no questions/issues related to this. 

Consuming OB Directory APIs and endpoints

MATLS setting up a transport connection with Directory services

There are no questions/issues related to this. 

Getting an access token

There are no questions/issues related to this. 

Payloads

Can we use X5C attributes in the payload itself?

Yes.

Software statements

Which schemes are supported in Redirect URIs?

Only https.

Signing and encryption keys

What values can I expect in the 'use' attribute for the OBIE JWKS?

We have values "enc", "sig" and "TLS" to indicate the use for encryption, signing or TLS (transport).

Software Statement Assertions (SSAs)

What eIDAS information is included in the SSA?

SSAs include the NCA ID, Org ID (enough details for the ASPSP to put together the org identifier) but does not include the NCA org identifier. OBIE is considering adding this. The org ID and the organisationIdentifier are in the eIDAS certificate  The org ID is in the SSA. ASPSPs can query the TPP endpoint using the org ID to fetch the organisationIdentifier and check whether it matches the eIDAS certificate.


How many ASPSPs trust self-signed SSA’s?

The consensus was that these are not trusted. In this scenario, ASPSPs would push TPPs to OBIE. NOTE – the SSA is the front door key to all OBIE ecosystem ASPSPs.


What is the meaning of the "organisation_competent_authority_claims" "Status" attribute?

The "status": "Active" attribute indicates that the organisation is Active within the UK Open Banking ecosystem. The SSA API endpoint returns a list of objects that represent PSD2 roles grouped per country. When one of the roles is revoked/withdrawn (not Active) they do not appear on the list returned by the SSA API.


When an organisation has the following claims on its SCIM record:-

{
    "urn:openbanking:competentauthorityclaims:1.0": {
        "Authorisations": [{
            "Psd2Role": "AISP",
            "MemberState": "GB",
            "Active": true
        }, {
            "Psd2Role": "PISP",
            "MemberState": "GB",
            "Active": true
        }, {
            "Active": true,
            "MemberState": "IE",
            "Psd2Role": "PISP"
        }, {
            "Active": true,
            "MemberState": "IE",
            "Psd2Role": "AISP"
        }]
    }
}

the SSA will have the following "authorisations"

"authorisations":  [
                {
                    "member_state": "GB",
                        "roles": [
                            "PISP",
                            "AISP"
                    ]
                },
                {
                    "member_state": "IE",
                        "roles": [
                            "PISP",
                            "AISP"
                    ]
                }
            ]

Should one of the "Authorisations" be marked as "Active": false as in

{
    "urn:openbanking:competentauthorityclaims:1.0": {
        "Authorisations": [{
            "Psd2Role": "AISP",
            "MemberState": "GB",
            "Active": true
        }, {
            "Psd2Role": "PISP",
            "MemberState": "GB",
            "Active": false
        }, {
            "Active": true,
            "MemberState": "IR",
            "Psd2Role": "PISP"
        }, {
            "Active": true,
            "MemberState": "IR",
            "Psd2Role": "AISP"
        }]
    }
}

the SSA will have the following "authorisations"

"authorisations":  [
                {
                    "member_state": "GB",
                        "roles": [
                            "AISP"
                    ]
                },
                {
                    "member_state": "IR",
                        "roles": [
                            "PISP",
                            "AISP"
                    ]
                }
            ]


ASPSP authorisation servers

What format should the file with the EISCD codes be in?

The file should have a .csv suffix.

Certificate validation service

Validation checks

For QWAC and QSEAL certs we check:

  • That the certificate is signed by a recognised QTSP by validating the trust chain up to the root certificate

  • The certificate is RSA (or soon a supported EC curve)
  • The certificate has a QC statement indicating the right cert type, containing at least one role
  • The certificate applies to the organizationIdentifier registered in our directory against the right entity
  • Validity checks
    • has it expired?
    • has it been revoked?
    • has its issuer (QTSP) been revoked?

​The Service will also return the NCA data related to the organisation regardless of whether they are participants or not if the NCA data is available.

NCA authorisation data


What is the timeframe for validation of PSD2 authorisation for participants and non-participants via DCR?

Currently, manual daily checks are performed for participants’ PSD2 authorisations. OBIE is working on automated checks of participants only (release date TBC). OBIE does not check PSD2 authorisations for non-participants manually.

The Certificate Validation Service returns the NCA data related to the organisation regardless of whether they are participants or not if the NCA data is available. There is a roadmap for ingestion of NCA data here: Technical Directory - scheduled deliverables


How are the new validation services supported in the Sandbox? Are the TPPs asked which certificate types they will support?

Directory services are released to both environments, so they mirror each other. You cannot use the Certificate Validation service in the OBIE Directory Sandbox to valid test eIDAS certificates. There are plans to enable this capability.

If you consider it a risk, TPPs could upload their Production QWACs / QSeals to Sandbox Directory for use against ASPSPs’ Test Infrastructure.

OBIE does not ask TPPs which certificate types they will support through the service.


How do I validate non-OB participants?

You can use the Certificate Validation service. Or directly use the OCSP or CRL endpoints in the eIDAS certificate for validation of the certificates.


How often can ASPSPs hit the validation service? Are there any capacity constraints?

There is no limit to usage. The service is scalable, so it should be able to cope with any volume, but a caching strategy of certificate checks can be adopted.


Will OBIE offer services to validate QSEALs at the network layer?

Currently, ASPSPs can check via the OCSP endpoint (or via CRL if OCSP is unavailable), plus the certificate is checked every 10 mins. Alternatively, ASPSPs can hit the OB Directory Certificate Validation endpoint.

Dynamic Client Registration (DCR)

All the AKAs

What are all the ways that DCR is referred to?

  • DCR.
  • Dynamic Client Registration.
  • Headless enrolment/registration.
  • Automated enrolment/registration.
  • Programmatic registration/onboarding/enrolment.


Does DCR with OBIE conform to the DCR spec for registering with ASPSPs?

It does, in principle. The end result is an OAuth client, but the onboarding payloads are different.

The OB DCR payload represents an organisation, the ASPSP DCR payload represents a software statement.

But, in both cases, you get an OAuth client.

QWAC based

There are no questions/issues related to this. 

QSeal based

There are no questions/issues related to this. 

Single Sign-on Service (SSO)

Dynamic registration with QWACS/ QSEALS. How does eIDAS certificate based DCR affect ASPSPs who want to use OBIE as an identity provider for SSO given that there will be no contact details for technical contacts?

Some banks use OBIE as the service provider for ID&V. OBIE undertakes full enrolment & ID&V for technical contacts. No contact details are submitted for DCR, therefore OBIE cannot perform ID&V for technical contacts via DCR. eIDAS is all that is required for PSD2 identification. If an ASPSP wants to offer Developer Portal (to avoid confusion with OB’s Dev Zone) services to a TPP, the ASPSP can send the TPP to OBIE for enrolment, before or after DCR, so that their technical contacts can undergo ID&V checks and can they use their OBIE login to access the ASPSP’s Developer Portal.

Organisational Records

How do we change our National Competent Authority (e.g. Companies House) or National Competent Authority (e.g. FCA FRN) registration number in SCIM?

Please have your Primary Business Contact (PBC) contact Open Banking via the Service Desk at ServiceDesk@openbanking.org.uk if you need to change records.

Multifactor authentication with Ping One

There are no questions/issues related to this. 

Delegated OCSP responder issue and impact on QTSPs

An issue has been raised regarding the use of the OCSP Signing EKU (Extended Key Usage) in issuing CAs. Specifically, where the use of delegated OCSP responders create potential security issues. This is due to the presence of the OCSPSigning EKU on an intermediate certificate. OBL understands that this could affect close to 300 CAs and that it has been discussed at the CA/Browser Forum. Though primarily affecting TSPs that do not provide eIDAS certificates, some QTSPs are also affected. Affected QTSPs have asked their customers to revoke and replace their affected eIDAS certificates by the 31st October 2020.

OBL has raised the issue with five key QTSPs who represent the greatest volume of eIDAS certificates uploaded to the Technical Directory. Of these, 2 have confirmed that they are affected and have taken action, two are not affected, and one has not responded.

DigiCert have posted a very helpful blog that describes the problem: Working with Delegated OCSP Responders and EKU Chaining

  • No labels