While PSD2 APIs were meant to be ready for September 2019, it is clear that the versions that were delivered for that date are still improving, and that work has not yet finished.

This article describes a problem that has emerged with the PSD2 APIs, and the work that Open Banking Europe and many others have been involved in to solve that problem and move us closer to a security standard.

Disclaimer – This article touches on some very technical topics about cryptography and internet standards that I try to summarise in a more ‘everyday language’ to reach a wider audience. In doing so, I may aggravate some security experts, who will have a field day picking apart my explanations. Please go easy on me!

So what is the problem?

Well, I’m glad you asked! Basically, as part of “common and secure communication” between TPPs and ASPSPs, every bank in Europe has a different way of signing (or not signing) the API payloads that are exchanged between them, creating a fragmented landscape for TPPs.

Hang on! I thought we had TLS for secure communications between the TPP and the Bank? So what is payload signing? And why is it important?

Yes. You are right. Transport layer security (TLS) – especially involving an eIDAS certificate (QWAC) -provides confidentiality, integrity and (while the message is in transit) authenticity.

Think of TLS like an envelope that protects the letter inside it. The envelope protects the content of the letter from being read while in transit (confidentiality). If the envelope has not been opened or tampered with, then you know the letter you receive is the letter that was sent (integrity) and the postmark shows where it comes from (authenticity). But the envelope is then thrown away and has no/little value afterwards.

Signing (especially with a QSealC) gives non-repudiation, as well!

Non-repudiation?!

Yes! If I send you a physical letter and write “I promise to pay you 100 euros”, and I sign it then you have a piece of paper that witnesses that promise from me. If I do not deliver the money, then you have evidence in your hand. 

In the physical world, if you then add a zero at the end of the “100” and claim that I agreed to pay 1000 euros, then I will “repudiate” your claim. It then becomes a your-word against mine discussion.

In the digital world, and through the magic of cryptography and signing, the party sending the message can sign it in such a way that the signature is linked to the contents of the message that has been signed. If somebody tampers with the message later (e.g. by adding a zero), then the signature is no longer valid. This gives a good proof not only of WHO signed, but WHAT was signed.

The other benefit of signing, is that the person signing does not have to be the person sending the message (putting it in the envelope) – which is very important when so many outsourcing and technical parties are in the middle.

Finally the signature is persistent – it can be stored, and brought out four years later, in the case of a dispute. The TLS session collapses and disappears once the communication is finished. You can take it to a judge in court of law and supply it as evidence.

Oh yes. That is what I thought… but just remind me why payload signing is relevant to APIs?

Well the APIs are made up of a series of request and response messages between the TPP to an ASPSP. Each one is something like the letter.

For example:

• “Josephine asks me (the TPP) to ask you (the Account Servicing PSP) to pay John €100”
• “OK €100 has been paid”.

 Or

• “Joanna asks me (the TPP) to check that she has paid €100,000 to ABC Co.”
• “Yes, she has.”

Or

• “Vladimir wants his transaction history for the last three weeks”
• “OK. Here it is….”

Depending on the context it can be important to either the TPP or the financial institution or to both parties that they can trust the information they can get – not only now – but in the future. An asset can be transferred based on proof of payment, for example.

That is clear. So have all the banks implemented payload signing in the APIs?

Well, Open Banking Europe ran a survey of ASPSPs to see in March 2019. The results showed that most (if not all) banks consider signing important, as they understand that the information they receive or send may be needed in case of a dispute.

•  Some focus on the risk of the TPP later falsifying the information and so require the TPP sign.
• Some realise that there is a value in signing their responses, and do it.
• Some do not (yet) sign, as it didn’t get implemented in the rush to meet compliance deadlines with ever changing compliance requirements – but it’s on the to do list!

Anybody who has anything to do with security will agree that signing the payload is quite a basic security practice that at least some of the messages will need to be signed by one or other party.

Good. So a work in progress, then but otherwise no problem, right?

Hmmm. If only.

Having understood that signing is important the next question is HOW to sign. Signing is well understood and used in financial infrastructures but a number of issues appeared within the APIs. As you know most APIs are REST based JSON APIs. Don’t worry about what “REST JSON” actually is just go with it for now.

The most obvious way of signing JSON on the web is to use a Jason Web Signature (JWS) but there were some important security and fraud related requirements that made it tricky, as well as some data requirements about backward compatibility with other channels that meant that an out of the box JWS was not appropriate.

At this point different communities went down different paths. As part of the PSD2 extravaganza, there are at least six different PSD2 API standardisation initiatives in Europe – although not all produce ‘standards’ but ‘frameworks’ and anyway not all banks follow one of them and where they do they often implement them differently.

The UK and Polish communities adapted the JWS (which is permitted under the JWS standards) – although each community found a different way of doing it.

The Berlin Group and STET decided to adopt version 10 of a draft HTTP Signing standard that they found using a methodology called “HTTP Signing”. The draft standard was authored by a Mr. Cavage, and so its known by the experts as the “Cavage method” but lets keep him out of it – as he is American and didn’t know that on the other side of the Atlantic some of Europe’s largest financial institutions were about to pick it up and put it into a live environment for payment messages.

Quite… tell me more!

Well, taking an unproven standard and applying it to banking systems is generally frowned on, but it seemed OK, and there was an application underway for it to be made a proper internet standard, and anyway, signing is best practice not an explicit regulatory requirement and everyone was under a lot of pressure. It wasn’t clear that the JWS route was even possible, people had to do something, so they did their best and went with it. To be fixed in version 2.0…

This fell apart slightly when Cavage released a version 11.0 on April the 24th with at least one quite fundamental modifications, and a big disclaimer stating that this was an experimental draft standard and should not be used in a production environment. Still the rules around exemptions said that changes 6 months before go live, so there wasn’t much anybody could do at this point.