Mike Small - PSD2 – Does the RTS Prohibit Secure Customer Authentication?

Now, moving on to the next session. So in the next 20 minutes or so I'm going to give a talk about this subject, which is, does the regulatory technical standard prohibit secure banking. And when I've given this talk, I will then hand over to a panel that will be moderated by Martin carpenter. So this is a, an interesting subject, and I'm just trying to find the clicker, which is disciplinary. We've got the, so when you look at PSD to, we've going to have a quick recap in case anybody doesn't know what it is, this was the electronic payment services directive.

And since the, so few of you now recognize you all know what it is. This is really in, in, in order to explain some of the acronyms, which is that it, man, it mandates payment service providers must make account data information available to account information, service provided AISP and allowed payment initiation, service providers, PI IPS to make payments. And it also, oh there.

So it, it actually shows you how that would, that would work. It also involves some kind of question for how you would allow authentication now. So you might say this is all very straightforward, but, but in fact, I went to an open banking, an UK open banking, implementation entity meeting in January, where there was a lot of handing and concerns, which led me to believe that apparently it isn't all straightforward. So basically the question is very, very simple.

You, you, you have a bank, which is what was the original bank. You as a person may want to make a payment via a third party. And in order to do that, you're going to have to authenticate or, and authorize that payment with the, the end end bank. And so how does all this this happen? Well? So there's lots of different ways that this kind of thing all could happen and is already happening.

So for, for example, this actually happens all the time in Europe. If you are using a credit card, because with the Europay MasterCard visa system, then there is the notion that you, you, you go to a retailer at the merchant who might use a payment system provider, who, who effectively takes your credit card details. And at that point they may be checked with check and pin through, through, through certificates and so forth. And then that, that payment then is moved on to the, the actual final bank.

So there is already a way that works with credit cards, but really all that is concerned about is can you authorize this particular transaction is the, is this, it doesn't necessarily check on the identity of the person except through the possession of a pin. And he just wants to know, is the car valid and are the funds there? So if you then look at what's, what, what might otherwise work? You find that nearly every bank has some kind of a, an online web based interface. So one way you could do it.

And which clearly a lot of people would like to do it is through screen scraping and screen scraping says, well, we kind of have a view of what a screen looks like for using a particular bank, a bank's website. So what we'll do is we will write some kind of software that simply pretends to be an end user and fill stuff into this script.

And that's a well known, trying and trusted way of, of creating single sign, which those of, of us who've been around for a long time, recognize, and know how in securities, because basically it means that at some point you definitely will have a third party that is holding your password and that password may or may not be terribly well protected. Then there was in, I think it was 2001, November, 2001.

What was then called ESL became Sam, which is a way of creating identity Federation, or rather that you can say that one organization, a relying party will trust on another organization with identity provider that the identity that you provide is, is correct. And that says that in a corporate terms, you identify yourself to your employer and log onto that intranet.

When you then go from that intranet to a supplier, the supplier trusts the identity that was assertive guy, your employer in terms of the, the wider market there is, or too, and anyone who has used Facebook or Google has their identity will be well used to how, what you can do is effectively say, if you, if, if, if you want to know my identity, ask Google and Google will give a token that allows for access to a particular results. Now that is what seemed to have been developing into the open ID connect financial services API. And that is what was being used in the Obi E the UK banking APIs.

Now there may well be other ways that I've not talked about here that apply to other parts of Europe and so forth, forth. So what, what's the problem?

Well, when I went to this meeting and I discovered what was going on, it turned out that there is this thing called originator technical standard. And there is a draft which was published in November 27th or thereabouts 9 20 17, which when you read it, it contains a number of, of things relating to strong authentication. And I've actually picked out some of the things here that it actually says.

So it says, for example, the use by, so it basically says that if there is an interface, if you, as the, the bank, the ultimate bank provide an API, this dedicated interface shall ensure that it does not create obstacles such as preventing the use by PSPS of the credentials issued by ASPs. So what that means is that it's, you must not stop this third party payment provider from holding your, an name of password, which in general terms is not considered to be good security.

Then it says you must not create an obstacle such as imposing redirection to the ultimate bank's system for authentication, which actually ultimately prevents the use of SAML or of OLS two, because OLS two is a redirection, which results in a token, and you are not allowed to require additional authorizations or registrations or require additional checks of consent. So everybody at this meeting was ringing their hands as to how they were going to carry on, to deal with secure authentication. And so what they said was there were three potential ways of doing it.

One was the embedded authentication, and that is effectively that what happens is that the secure authentication first and second factors are transmitted to the intermediary and the intermediary then passes them on, which clearly is an opportunity for money in the middle. So if you allow that, it basically says, well, any kind of criminal who is clever enough to pretend to be an a, I S B PS, P I S B can set themselves up and behave like one and everything will be fine. So this does not seem to be a particularly secure way of doing things.

However, it may be the only way you're allowed to do it. Then the second thing that it, it talked about, they talked about was the redirected authentication. And this is really the way that it works with, with OLS too. And this is the way that the O B I E proposal was going to run.

And basically what happens is when you try to authenticate, you are redirecting to your bank or to Google or whatever, as the case may that if you successfully authenticate directly with the party that you are trying to gain access to, then there is a down where a token is sent back, which gives you authorization to press on and to do the transaction. And it's a bit more complicated than I've said then, but that's in essence of what happens.

And then there is the notion of decoupled authentication, which was the third method that they were talking about, which involves the use of a, another device. So for example, you can say, well, when I want to do something, the authorization will happen because I get to call with a number that's sent to my phone line, or I have another app on my phone, or I have another device. And that seemed to be the, the, the way it was being suggested. And people thought, well, that was, that would work, but it was actually quite difficult because it involves the use of multiple devices.

And not everybody has multiple devices indeed, that there was a lot of talk about how some, some banks want this to work where, you know, they, they don't, they have to deal with customers who may not even have above our firm and so forth. So this kind of left you in this problem of what we going to do. So just to kind of remind us, this is what the open banking system really works like, that it is based on and talk you through all of those things.

So here was the challenge that was being set, and I'm hoping that people are going to be able to answer that challenge so effectively, what it seems to me is, is that the, the way that this RTS is threatened, actually prohibits what I would describe as proven security techniques that it actually permits indeed encourages what I think is poor security practice. It seems to have been invented to prevent lockout.

It may have been lobbed for, by some of the swivel live dinosaurs that I was talking about, that it may be possible to implement it securely, but it certainly doesn't seem to be setting the, the scene for the future. And in effect, I think it could become a screen screen is chart. So I hope that I'm wrong, but if I'm not wrong, then it really is going to be up to some of the people in this room to take some action to, to deal with it. So do we have any questions? Anybody disagrees with me, it's a select audience now, Your questions.

So I think one thing is for sure that we a hardly bad written document, I think without any doubt you can say, you know, started was the fact that if only talk about interface, not even used term API at any place, that it didn't do a very good job on the stuff we had before about the open banking, I, or how do you standard as APIs? The discussions we had around is creating the regarding. So in fact, if you read it a little, it reads like risk based. Cation is not allowed anymore.

No, it is only if you only use one factor, there are limitations for good reason. And this has been already a little bit changed as we all know for at least a certain period. But in fact, obviously the recommendation should have been, oh, these two factors plus risk based application, the good written document would have made it very clear. It also have made clear which combinations of two factors are allowed, which aren't allowed all that is lacking in this document. So I would say amongst the regulations I've read so far, it's probably the worst I've seen.

And yet one of the most important to Yes. Yeah.

It's, it's a very, very function combination, you know, and very important regulation, which for a good reason has some, some big things inland that you kept saying, okay, that's a good thing to do as a special bank might say, okay, this not a good thing to do, but anyway, there was good reason behind, but what they did around, I think around both areas, when it comes to the technical side of things that is trust, how can I work this four letter word this year, R AP, this is trust, nonsense, just a board that done. And I think this is what leads to all this discussions.

And yes, we have this screen greatly. We have from some lobbying of organization, you know, and with all the bad work done around APIs and interfaces, you open the door to the screens, creating discussion. So obviously the other side, but the other hand, you know, when I've read, I think it's eight months ago or so last year may when this 70 German companies came out and said, oh, we want to, to, to have screens scraping and, and FinTech request screens scraping.

I said, okay, there's probably a sort of dichotomy because if you're a FinTech that you ask for the stone edge screens scraping my view, it's it doesn't fit each either. So either your tech or not, but if you're, if you're the one you should ask for, for totally outdated technologies, so Is a scope for RGS too soon, like a super seeding document, maybe. So it should be.

Yeah, definitely. Yeah. But yeah. Will that happen?

Doubt, but there would be a need to do a better job on that. Yes. So maybe PSD two and a half, something like that With this for at least a couple of years, right. And this is not going to change.

And I, I have the same adversity of against swing sweeping as you have, but you know, you can do it tomorrow. If you're a FinTech, you know, you wanna do something tomorrow and not wait for three years. So Yeah. You can do tomorrow, You Know, I think honestly, technically see where's, where's the problem. Okay. You have 70 bank APIs, but all these bank APIs more or less allowed say stuff to do, because what they need to enable that pretty clear. Okay. So you have 70 APIs and you have one tool. What do you do as a software architect?

We say, okay. I look at the 70 look at where are the similarities I create my own API, create a Porwal and I match to various APIs. That's not rocket science, it's standard software architecture work, then All over the T and provided there's one API. Yeah. It would be better to have one API, but you, for my tool log, I can say, okay, that's my way I interface. And if there, and I probably would use the open banking API as sort of my, my guide. So that's basically the way I, I address it to that. Then I invest the time in some records, but I don't need to change my application code.

That's just standard good software architecture practice. And if any single secure of FinTech accounting says, I would, I can't do that. I want to have screen scripting then. Is there any single CTO for FinTech in the room I used to be? You Used to be okay. That's different. It's I would say, you know, I hate that obviously for Screening. Yeah. If you ask green, I, then you better look for four different job. Yeah. So you can even, but you know, I think you met my point, I think the challenge discussion.

So, so of arrives from the fact that the RTF is that below average. Yeah. What's the reason behind that actually. Why what's the ultimate reason? Why is that such a low average? I haven't been close enough to judge about it. Maybe someone in room and it looks like we have an opinion why this, I say it's just because there's no, no big interest actually from the bank side together, banking like working.

So why, why at all Banks Really come up with API? That's the question? How many banks are really published in? Yeah.

You know, from, from a traditional bank perspective is if I make it hard for a party provider to interface with my system, I will stay in business a little longer. Yeah. And then mess up the security model and then customers don't trust us. You stop. Yeah. And even takes longer. Yeah. Right. Yeah. Yeah.

Yes, obviously, but you know, when I'm a regulator, that is, you say, I want to have regulation. I clear target, which is to foster competition. That is my truck is EU to care for that at least to care for that output is good. And then at that case, at the end, we have to blame EU, which is anyways, pretty easy. Always. That's the good thing. The good thing is we know we don't, don't hit on someone who hasn't earned it, How's it in the case actually a difference.

Are they, are we trying to go in a different way in a different Direction? Well, no, because we are still you, I know we are leaving, but at the moment we are still behaving until we, until the day we're in. And what has happened is that the, the, the PSD two regulation, the PSD two directed has been translated into a statutory, a statutory instrument. I E it is a binding UK or which is a technical instrument. That's sort of implemented by the financial conduct authority. And this has turned 44 pages of, of PSD two into 124 pages of technical standard.

So, so we are implementing it. You mean, be, it seems to me, from what I have seen that the Oakland banking implementation entity, which has been settled is actually trying to define a, within the parameters, a secure set of APIs that are intended to do what is necessary. So they allow these APIs allow things like being able to find out stuff. They are what they call, read APIs that can look for ATMs and so forth and, and functionality that things will provide. And there are also sort of in a sense update APIs of which the one that I've been talking about is what they call the security profile.

And the security profile is based on derived from the open ID, connect, financial services API. In fact, that is the basis for this. So it seems to me, the, the UK is quite well advanced. He's a published or are documents on the website and people have written prototypes. That's I would say, UK is the one who really control on that.

Yeah, I'd agree. So agree. Absolutely.

They, they, you know, I, I, I have the opportunity of traveling around Europe and having a lot of discussion about how banks are addressing BSD two. And, and it's clear to me that the UK is, is well ahead well down the path. And I think what's been critical is the, the use of established security standards to enable that confidence in opening up what is some of our most sensitive data. And we at for drop built model bank for the open banking implementation.

So that TPPs are now coming onto that testing the API specifications against the standard so that they can ensure that their app is, you know, working functionally and also is compliant. So, so There might be some hope that's going back into the, at Some point.

Well, I think so. I think so. It's not to say that the, you know, the embedded route has some significant security concerns. There are some mitigating factors using biometrics and the way you deploy the kind of browser inside and we're involved in some POCs that are, that are directly related to that.

But our, our recommendation is to use O two open ID connect, the FPI profile, and also Uma the user managed access, which is another profile of, of our two as well. Okay.

Well, thank you very much. So we're nearly out of time. So I'm going to hand over to my colleague Matthias, who will take over the next Absolutely fine. Not problem for me. Okay.

Well, thank you very much, ladies.