Requirements

To access these APIs a PSD2 Qualified TPP will need to fullfill the following requirements:

  1. Create a TPP account on our developer portal, which is completely free and doesn’t require any approval by MEO Wallet. Depending on the target environment you can create one here:
  2. Have two PSD2 eIDAS certificates: a Qualified Website Authentication Certificate (QWAC) and a Qualified Sealing Certificate (QSealC), both acquired from a Qualified Trust Service Provider (QTSP).
  3. Have an OAUTH2 compatible client. You can manage your OAUTH clients on your TPP Account. For each OAUTH client you must define:
    • A name and an optional description
    • The scope/APIs to which the client will access to. The selected scopes must match the TPP roles present on your QWAC certificate
    • The Authorization Number present on the TPP QWAC certificate that the client will send in each request to the API
    • The OAUTH2 redirection endpoint that will be used for the OAuth 2 authorization code workflow

Mutual Authentication (mTLS)

On all APIs requests, the TPP must provide his Qualified Website Authentication Certificate (QWAC). The certificate must be valid for the API scope (aisp or pisp) of the request.

Payload Signature

Requests to service (AISP or PISP) APIs must be signed with your QSEAL certificate. Furthermore the TPP must provide on the tpp-signing-certificate HTTP Header his own public QSEAL certificate. Below, there’s a list of the basic steps to create the signature. For further clarification you can check the following reference.

To create a valid signature to be used in the PSD2 services, you must follow these steps:

1.TPP-Signing-Certificate Header

Use your (PSD2) eIDAS QSEAL certificate issued by the Qualified Trust Service Provider of your choice.

  • The certificate must sent on HTTP Header TPP-Signing-Certificate: The PEM-formatted certificate of the QSeal used for signing the request, after having removed the prefix line -----BEGIN CERTIFICATE-----, the postfix line -----END CERTIFICATE----- and any newline characters, leaving the Base64 part.

2.Create the Digest Header

The digest is a base64 encoded hash of the body: Base64(SHA512(body))

Take the body of your request or an empty string if there is no body. Pass the body through the SHA-512 hashing algorithm (SHA-256 is also allowed). Make sure the hashed output is binary. In other words; do not convert it to a string. Base64encode the output. Add the result to your digest header and make sure that you declare which hashing algorithm you have used.

An example of the digest header for an empty body using SHA-256 or SHA-512:

  • digest: sha-256=47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=
  • digest: sha-512=z4PhNX7vuL3xVChQ1m2AB9Yg5AULVxXcg/SpIdNs6c5H0NE8XYXysP+DGNKHfuwvY7kxvUdBeoGlODJ6+SfaPg==

Known issue: due to security regulation, spaces or line breaks between JSON elements will cause incorrect digest error.

More information: RFC 3230

3.Create the signing string

The signing string contains several headers depending on which API you are using, separated by line breaks (\n). The order is not important as long as you define them in the same order in the signature header.

For example:

date: Tue, 18 Sep 2018 09:51:01 GMT
digest: sha-512=z4PhNX7vuL3xVChQ1m2AB9Yg5AULVxXcg/SpIdNs6c5H0NE8XYXysP+DGNKHfuwvY7kxvUdBeoGlODJ6+SfaPg==
x-request-id: 95126d8f-ae9d-4ac3-ac9e-c357dcd78811

Headers included in the signing:

  • digest
  • date (if available)
  • content-type (when there is a payload)
  • content-lenght(when there is a payload)
  • x-request-id
  • All available PSU-prefixed headers

4.Sign with your private key

The signature is the signing string signed with the private key: Base64(RSA-SHA512(signing_string))

  • Create the signing string (see step 3).
  • Sign it using RSA-SHA512 (RSA-SHA256 is also allowed) with the EMSA-PKCS1-v1_5 encoding and the private key of the signing certificate.
  • Base64 encode the output.

An example of the signature using the above information:

HDsh1QjiH7bG0/+7W4s6HdEIy0ksCu6BoAb4VkasMvT5DO+ahZWi4dmX86g57BSu24sOdURptUyJUPdiBVNCJ1a2b5Ue8JEfzxg2aW3QVNtImVs7KFdAFdOgxwwtApJrfX9E2y1O0hr7jFAMvMHGZtmEIdqmMMWjDqQfqRErfGwNcNynZoTDe/N0YhmMiiISEWZdiw4f8zuvVH3bjOxqyBmUUQrOQO3HCHXUGiVm5NZMTFfEnYXxX5kBDyye4mnTHS7VO8e6OwYlmaAz3mCdqeIIyCUjB7uKiq0aBHcdKWhK6HfPNxbVxmapUAwud0eOcivFoR80eo4hLHLwmG9amw==

5.Signature Header

The signature header consists of the following components:

5.1. keyId - Serial Number of the TPP’s certificate. This should match the serial number in the TPP-Signature-Certificate header of this request. This number can be found executing the following command: openssl x509 -in qseal-cert.pem -noout -text.
The serial number can be found under Serial Number, eg: 6a:a3:…..19:03. Pass the value removing colon punctuation marks.

5.2. algorithm - Specifies which algorithm was used when generating the signature: rsa-sha512 or rsa-sha256

5.3. headers - The list of headers contained in the signature:

  • lowercase
  • separated by a space
  • in the same order as they have in the signing string signature
  • the result from step 4

The resulting signature header for our example:

signature: keyId="5D3E79AAE2EF293246323119FFAA5E80",algorithm="rsa-sha512",headers="content-length x-request-id content-type digest",signature="HDsh1QjiH7bG0/+7W4s6HdEIy0ksCu6BoAb4VkasMvT5DO+ahZWi4dmX86g57BSu24sOdURptUyJUPdiBVNCJ1a2b5Ue8JEfzxg2aW3QVNtImVs7KFdAFdOgxwwtApJrfX9E2y1O0hr7jFAMvMHGZtmEIdqmMMWjDqQfqRErfGwNcNynZoTDe/N0YhmMiiISEWZdiw4f8zuvVH3bjOxqyBmUUQrOQO3HCHXUGiVm5NZMTFfEnYXxX5kBDyye4mnTHS7VO8e6OwYlmaAz3mCdqeIIyCUjB7uKiq0aBHcdKWhK6HfPNxbVxmapUAwud0eOcivFoR80eo4hLHLwmG9amw=="