PSD2 QSealC signed message

Question

I have looked everywhere for an example of a QSealC signed message, and I could not find any info. I need to verify the signature of a QsealC signed payload AND I need to sign the responding payload but I understand that the payload is all in json,

Are there examples out there of QSealC signed payloads?

thanks

Answer 1

You will do both the signing and validation as detailed by IETF's draft-cavage-http-signatures, where you should pay special attention to section 4.1.1 for constructing and section 2.5 for verifying the Signature header.

This draft is referenced by both Berlin Group's XS2A NextGenPSD2 Framework Implementation Guidelines and Stet (France). However, note that it's normal that each unique implementation imposes additional requirements on the HTTP Message Signing standard, e.g. by requiring specific headers to be signed or using a specially formatted keyId. I am not sure whether other standardizations such as Open Banking (UK) reference it.

Take note that you do not need actual QsealC PSD2 certificates to begin your implementation work of neither the signing nor validation process, as you can create your own self-issued certificates, e.g. using OpenSSL, by adding the OID's found in the ASN.1 profile described in ETSI TS 119 495.

However, I strongly recommend you find a QTSP in your region and order certificates both for development and testing, and for use in production when the time comes.

I won't go into details on the actual process of creating the signature itself, as it's very well detailed in draft-cavage-http-signatures, but consider the following example;

You're requesting GET https://api.bank.eu/v1/accounts, and after processing your outgoing request you end up with the following signing string;

date: Sun, 12 May 2019 17:03:04 GMT
x-request-id: 69df69c1-76d0-4590-8f28-50449a21d0d8
psu-id: 289da2e6-5a01-430d-8075-8f7af71f6d2b
tpp-redirect-uri: https://httpbin.org/get

The resulting Signature could look something like this;

keyId=\"SN=D9EA5432EA92D254,CA=CN=Buypass Class 3 CA 3,O=Buypass AS-983163327,C=NO\",
algorithm=\"rsa-sha256\",
headers=\"date x-request-id psu-id tpp-redirect-uri\",
signature=\"base64(rsa-sha256(signing_string))\"

The above signature adheres to Berlin Group requirements as detailed in Section 12.2 in their implementation guidelines (per. v1.3), except some linebreaks added for readability, which in short are ;

1. the keyId must be formatted as SN={serial},CA={issuer}, but note that it seems to be up to the ASPSP to decide how the serial and issuer is formatted. However, most are likely to require the serial to be in uppercase hexadecimal representation and issuer formatting in conformance with RFC 2253 or RFC 4514.

2. The algorithm used must be either rsa-sha256 or rsa-sha512

3. The following headers must be part of the signing string if present in the request; date, digest, x-request-id, psu-id, psu-corporate-id, tpp-redirect-uri

4. The signature must be base-64 encoded

As developers have just begun to adopt this way of signing messages, you'll likely have you implement this yourself - but it's not too difficult if you just carefully read the above mentioned draft.

However, vendors have begun supporting the scheme, e.g. Apache CXF currently supports both signing and validation from v3.3.0 in their cxf-rt-rs-security-http-signature module as mentioned in the Apache CXF 3.3 Migration Guide. Surely, others will follow.

Validating the actual signature is easy enough, but validating the actual QsealC PSD2 certificate is a bit more cumbersome, but you'll likely have to integrate with EU's List of Trusted Lists to retrieve root- and intermediate certificates used to issued these certificates, and form a chain of trust together with e.g. Java's cacerts and Microsoft Trusted Root Certificate Program. I personally have good experiences using difi-certvalidator (Java) for the actual validation process, as it proved very easy to extend to our needs, but there are surely many other good tools and libraries out there.

You'll also need to pay special attention the certificate's organizationIdentifier (OID: 2.5.4.97) and qcStatements (OID: 1.3.6.1.5.5.7.1.3). You should check the certificate's organizationIdentifier against the Preta directory, as there might be instances where a TPP's authorization is revoked by it's NCA, but a CRL revocation hasn't yet been published by it's QTSP.

DISCLAIMER: When it comes to the whole QsealC PSD2 certificate signing and validation process, I find both Berlin Group and EBA to be very diffuse, leaving several aspects open to interpretation.

This is a rough explanation, but hopefully it give you enough to get started.