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!
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.
- “Josephine asks me (the TPP) to ask you (the Account Servicing PSP) to pay John €100”
- “OK €100 has been paid”.
- “Joanna asks me (the TPP) to check that she has paid €100,000 to ABC Co.”
- “Yes, she has.”
- “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.
So where are we now?
Whether the HTTP Signing is fit for purpose or not, the practical outcome for TPPs is that between the 4,000 banks there is every sort of signing algorithm variation being used: Some APIs don’t require signing at all, some do but in one direction only, some in both directions. Some APIs work with one variant of JWS, others need a different variant of JWS, some are using one of the HTTP signing versions….
While it is not the fault of any bank, every ASPSP is different, and no single ASPSP is using an industry standard commercial off the shelf technology, which makes it expensive for TPPs to develop against.
How sad – so that’s it then?
Well no! Open Banking Europe (OBE) were aware that this was happening and the European Telecoms and Standards Institute (ETSI) had become concerned and issued a communication about the way that eIDAS certificates were being used to secure PSD2 APIs. OBE and ETSI work together, and we called a working group, getting people together in the room to talk about it. This included the API standardisation bodies and the QTSP / eIDAS security professionals. The aim was to understand the requirements, to understand the current implementations as described by the standardisation frameworks and try to find a way forward.
The group also considered the requirements with the ETSI suite of “Advanced Electronic signature standards” (*AdES), where today ETSI have XAdES for XML signing, PAdES for PDF signing, CAdES for file based Content, but the JSON based “JAdES” is still in the pipeline – otherwise, presumably everybody would have used that!
We wanted to see if there is a single signing methodology that meets all needs, and apparently, there is! Moreover, the technical representatives of the different standardisation initiatives are happy to go down this route, as long as the new methodology really does meet their requirements.
Wow! Hooray! Terrific! So what happens next?
Well – let’s not get ahead of ourselves, we are probably a few months away from a public document, but Open Banking Europe has commissioned a specific JWS profile which is now being finalised. This draft will be distributed to the group described above, discussed and (hopefully) agreed. This will be lodged in the official JWS (IANA) repository and made public to avoid additional fragmentation.
The JWS profile will then be taken and offered to ETSI as the basis of a JAdES standard at some time in the future – at which point it will be up to ETSI to decide whether and how to take it forward.
While the standardisation initiatives, will then have to go through their own governance – there is optimism that if such a profile can be created that meets all the requirements, then they will converge to a new security profile in a subsequent version of their API standards.
ASPSPs will then presumably migrate forward and Europe will end up with a single payload signing methodology and TPPs will have one less problem to worry about.
Great stuff! Can you give us a hint about this security profile?
If I say, that it’s basically defining a profile of RFC 7515, using compact serialisation, using a detached signature, and a set of defined JWS JOSE header parameters, and allowing but not requiring the x5t#S256 hash and a load of other stuff… does that mean anything to you?
Good Lord! I think that’s quite enough for one day! Thanks.
No problem. You’re welcome.
For transparency and in case it is not obvious, I work for OBE, and so this imaginary dialogue is just a way or explaining a bit about what I and OBE and ETSI and many colleagues from around Europe have been doing to help standardise PSD2 APIs and Open Banking. The payload signature work goes towards an eventual “OBE API Security and Identity Standard” (OASIS) which is one element of our work program funded by our members.
Contact us at OBE to find out how you can join our membership programme and get more resources like these.