Complying With PSD2: Everything You Need to Know

Good morning or good afternoon. I'm John Tolbert with pooping or Cole today. Our webinar is supported by phyto Alliance and our topic is complying with PSD two. Everything you need to know. And with me today, we have Alan Martin, who's representing Fido and he's the head of consulting and industry relations at Alice. So before we begin a little bit about us co and coal, we're a global Analyst company specializing in identity and access management, cyber security and artificial intelligence. We produce various kinds of research. We do events and webinars, and we do advisory projects, which are very high level kinds of consulting. We call it on the research side. We have four major report types. Our leadership compass is a comparative report that looks at all the different products or services in a given market and identifies the leaders. It tends to be quite technical. Our executive views are five page overviews of a specific product or service by a vendor. And we always end with an objective strengths and challenges section and advisory note is more like a research paper, but in that it doesn't focus on products or services, but specific technologies and they can be much longer form. And then the shorter form of those are our leadership briefs, which are usually around two pages and designed to get some concrete advice to business leaders.
On the advisory side, we have strategy compass where we help customers develop long term technical strategies around IM cybersecurity and AI. The portfolio compass. We do requirements analysis, look at the current portfolio, figure out what may be missing and help customers develop roadmaps to transition to that technical compass is a more in depth requirements analysis, where we look at use cases and ultimately either help the customer design an RFP or, or work with them through the, the tools choice process. And then lastly, a project compass is some very specific, short period duration project management assistance to help execute some of these other compasses.
Our research, we have a new content platform it's easily searchable it's available online. And probably the easiest thing about it is licensing for 800 euros. You get full access to all of our research for a year and some of our upcoming we've got the cybersecurity leadership summit and cyber access summit in Berlin middle of next month. We also have AI impact at the end of November in Munich cybernetics world coming about this time next year, of course, our flagship event, EIC European identity and cloud conference is in Munich in may. So about the webinar everyone's muted, we'll take care of that, no need to mute or unmute yourself. We will be recording the webinars, always the webcast and the slides that you'll see today should be available for download by tomorrow. And there will be a Q and a session at the end of the webinar. If you look in the go to webinar control panel, you'll see a blank for questions, and you can feel free to enter questions at any time during the webinar, and then we will take them at the end.
So again, I'm John Tolbert lead Analyst here at COO Nicole. I'm gonna start off talking about, you know, a little overview of PSD two and strong customer authentication and how mobile biometric authentication can play a role in that. And then I will turn it over to Alan and then we'll take questions at the end. So PSD two, an overview PSD two is the revised payment service director. You know, I think it's really interesting to note that as a directive, rather than a regulation, its implementation is proceeding quite a bit differently than let's say GDPR. I'm sure everyone remembers last year, the run up to GDPR as a regulation, you know, it applies across the EU at the time it goes into effect. PSC two is a directive is implemented a little bit differently and then has to be enacted into law by all the member states, the European banking authority oversees the PSD two and it technically went into effect the regulatory technical specifications that we'll look at in some more detail. This hour actually went into effect on September 14th, but as you may or may not have seen in the news, there are some individual countries are announcing that they're gonna be delaying enforcement of the regulatory technical specs for differing periods of time.
So what were the motivations for PSD two first and foremost, you know, there's the single Euro payments area in making it easier to use a single currency across all member states, still a goal. And to level the playing field, there are lots of financial technology, or we call it FinTech companies out there that, you know, have been trying to get more and more into the actual payment processing side. PST two helps level that playing field. There's a lot of interesting and, and much better technology available on for payments processing that can actually increase the security of payments. So that's one of the goals that EBA had as well as protected consumers and then ultimately to help reduce the consumer costs for payments because as you probably know, transaction costs can be quite high depending on the, the recipients and the location, and however many clearing houses they may have to go through 'em. So ultimately it should be a big benefit for consumers. It should provide additional competition in the market, which you know, can drive down costs and, and then yeah, improve security, definitely a high goal there because of the increased amounts of fraud that are, are being seen across the world.
The two major technical bits to PST two are strong customer authentication or SCA, and then the need for banks to put APIs into place. So SCA requires the payment service users or, you know, consumers and banks and various financial services have to be strongly authenticated unless certain conditions are met and that's strongly authenticated for every transaction unless these conditions are met. And I'll show you that in just a minute, you know, on the API side, we're not gonna really talk about that much in this webinar, but this is a major thing that banks are having to put into place. PSC two essentially directs them to open up their core banking functions to third party providers to facilitate both payment processing and account inquiries. So security is of the utmost concern for the API implementations as well.
The third party providers, there are two major kinds account information, service providers and payment initiation service providers that kind of perform the services that you would think by the name, being able to get balance inquiries or, you know, for example, account aggregation apps. So you've got multiple or accounts of multiple banks and you wanna see your, your, your total balances. There are some innovative apps out there that can do that for you at a secure way. Payment initiation, service providers, direct initiation payments from consumers to vendors. These functions have really been historically been performed by banks in other entrenched kinds of businesses there in the financial sector. But now we're going to see an increase in the number of competitors and sometimes from non-traditional or non banking types of businesses. And of course, many fintechs entered this market specifically to be able to provide these kinds of functions. And we're seeing a definite increase of the number of mobile apps that include authentication for a I S P and P I S P functions. One of the other often overlook things is that trust frameworks have to be put into place between banks and TPP. That's the, the, the grid that will connect the various fintechs TPP to banks and make this work.
So for strong customer authentication, it's defined in the most common way where it's two of the three of, you know, either something, you know, something you are or something you have, and then doing the transactional risk analysis in between those strong authentication events to mitigate the need to actually do one of the strong customer authentication actions every time, and some simple examples of on the API side, you know, for third party providers being able to get account information, bank accounts, get transaction types that are supported. And again, API security here is paramount where federated trust and authentication and authorization for the individual services is necessary as is network security.
So there are some exemptions to PSD, two low value payments payments that you might make it a kiosk, maybe a parking meter at a train station transactions for which transactional risk analysis can be performed. And I think of this as like a combination of user behavioral analytics plus risk adaptive or continuous authentication concepts. And we'll dive into that in just a minute recurring payments or subscriptions where the merchant will store your card info. That would be that case trusted beneficiaries. You can actually whitelist businesses that you wanna do business with. So you don't have to do the strong customer authentication each time mail order, telephone order, and then corporate and credit card payments. This is specifically for like business travel or maybe credit cards that are held and used on behalf of clients by travel agents.
So why mobile is important here? Mobile is that second channel mobile is much more widely used today, especially on the banking side. Customers are used to that. So some things to consider here, alright, let's say native mobile apps say a bank has decided to develop a mobile banking application. Hopefully they've decided to use an authentication provider that has a nice, strong and secure SDK in which to build that. So you've got, you know, native authentication authorization that can be built in, and then also use things like global platform, trusted execution environment, secure element for storing keys, there's storing keys and secure enclave in the case, iOS mobile push notifications, that's, you know, get the pop up swipe to authorize or swipe to accept mobile biometrics, touch ID, face ID, Android, Samsung. These are well known. I'll talk about this in a bit more detail in a few minutes.
Also, there is still SMS OTP, or getting a passcode texted to you. It's been deprecated by us nest for security reasons, but still widely popular around the world. And then lastly here Fido two, I like Fido for a variety of reasons. It's great for mobile. It's great for other kinds of second factor it's privacy preserving, and probably best of all from an architectural perspective, it's easy to use different phyto authenticators, and there are plenty and many of them to be had that have been certified that do use secure technologies like global platform, and there a variety of biometric modalities that are supported there.
So for PSD two mobile is important because it is that second factor in the case of entering a pin into a mobile app, it's that combination of something you have, it's something, you know, if it's biometrics, it's something, you have something you are, and this is a perfect place for Fido. So a little bit about the biometrics and how they work fingerprint, you know, that's matching the minutia, the patterns and the minutiae on your fingerprints at run time versus a registered sample doesn't work well for everyone. There's certain populations. The fingerprints are not as easily readable facial recognition taking a selfie. This is looking at the geometry of the face problem here is that, you know, even sometimes slight changes can make it somewhat difficult to use this, you know, whether or not you've shaved or wear makeup or hat or glasses that can interfere with the proper operation of facial recognition voice at registration time, you can either do a dependent phrase, you know, and when you want to authenticate, you say that same phrase, or if it's text independent, that increases usability, Iris, you know, the colored part of your eye, it actually has the highest number of analyzable features or degrees of freedom.
And one of the best things about it is it doesn't change aging. Lastly, we've got behavioral biometrics, which are sometimes called passive biometrics, and here's a little more of a look at that. That's things like keystroke or mouse analysis in the case of, you know, the user using a keyboard or a computer swipe analysis on a phone touchscreen analysis, also on the phone or on a tablet, you know, how hard you press against the screen gyroscopic analysis, how, how do you hold it and interact with it, drawing gestures on the screen for gesture recognition, things like network. Is it a common wifi, S S I D that you're on keeping track of that mobile network information as well. And then there's other kinds of things that would qualify as passive biometrics, believe it or not, these different factors kind of add up to present a pretty good method for saying that we believe this person who's using the device is the same person that that has been registered to after creating a baseline of normal behavioral patterns.
So a couple other things about biometrics there's ther the false acceptance rate and the false rejection rate, false acceptance rates health, and a bad guy might be able to, let's say, take control of your phone by submitting an improper sample for comparison false rejection rate is if you've ever used any of these, this would be the experience you get when you try to swipe your own finger on your phone, and it won't let you in because it doest recognize it. Generally the, the trade off point we call the equal error rate, where they meet is between usability and security. So you, you want to make sure that people who are not authorized or who are not, you can't get access to your information, but it shouldn't keep you from getting access to your information.
There are a few other things to think about with regard to biometric security. It's not just the runtime comparison between the, the sample presented and then the registered sample, but think about enrollment threats, or, you know, have, let's say a bad guy, getting their biometric sample linked to an illegitimate account so they can, you know, get access to someone else's credentials. So in essence, you know, you could do that perhaps if it's unsecured on the phone by stealing the biometric samples, if it's not, you know, properly locked up the way it should be biometrics are in secret, you know, a lot of PKI and a lot of things that in the security world kind of revolve around the confidentiality, integrity, availability, triad. So since biometrics aren't secret confidentiality can't really apply so much here. Integrity is important. This is again, integrity, the biometric sample. And then lastly, presentation attack detection or liveness detection.
You know, we've probably seen many examples of movies where somebody's trying to defeat a biometric authentication system by, you know, using a picture or, or, you know, a copy of a thumbprint. Of course, malicious actors have gotten more and more sophisticated over the years and now, you know, 3d molds or printed molds are being used. So liveness detection can be a way to help prevent these kinds of attacks. And this would be something like in the case of fingerprint where, you know, it's looking at temperature or whether or not there's perspiration, you know, you, if you're doing a selfie or an Iris scan, you may be asked to blink that again, kind of helps show that it's not a picture that you're holding up. So again, that's another important thing to consider when building out biometric authentication systems, just kind of a high level snapshot of where I think biometric modalities are today.
Overall, you know, fingerprint is still most commonly used. It's got a lot of things in its favor, you know, pretty good F R torr, pretty unique. I think most of the major apps report that it's about the same as a six digit pin in terms of uniqueness. So about a one in 10,000 chance for error, they're reasonably persistent, pretty easy to use facial recognition. Like I said, has some operational problems. I think it's, it's one of the least useful, but then you've got things like voice and Iris, which are actually pretty unique and have, you know, a decent amount of persistence and are fairly easy to use, but they're, they're still not widely used compared to say fingerprint. And then there's the behavioral, which, you know, can, can over time develop a baseline, such that it can easily discriminate a, the right user from the wrong user, but it takes time to train up and get that baseline. But I think we're gonna see more and more usage of behavioral or passive biometrics in especially banking kinds of applications or PSD two use cases.
So looking at the transactional risk factors, there's identity analytics, I would call it, you know, frequency and time of logins and number of failed login attempts, attempts to change the profile. And then looking at the, the history, you know, is this a transaction type that the user's done before? Does it fall within the range of amounts that they've done before and with the same frequency? So these kinds of things, if they all fall, you know, in that same pattern, then it's likely that a user wouldn't be required to reauthenticate, but you have to develop a large amount of data to compare that against. So it's important to, you know, collect data on individuals and their usage for long periods of time to be able to get that baseline.
And then there's also things that I broadly called threat intelligence, like IP network and reputation, geolocation, or geo velocity, geo velocity, being impossible, travel as called by some device fingerprint. That's not the fingerprint, but it's sort of like an amalgamation or a signature of different components of the phone to kind of give it its own, you know, unique digital fingerprint and device health assessment. I think we're gonna see a lot more use of mobile. Anti-malware one of the provisions in PSD two, that doesn't get a lot of airplay, but is, is nonetheless still part of the RTS is that users should be assured that malware is not interfering with any part of a transaction. So I think this means both, you know, behavioral analytics and, and let's say botnet detection, I'm part of FinTech and banks, and then also mobile anti malware on consumers devices.
So transactional risk analysis across time. This again is just, you know, looking at how these various risk scores may change across time. And, you know, as long as the preponderance of risk factors, don't change too much, you should be able to scoop through, you know, the 90 days that are mandated by PST two to not require necessarily a strong customer authentication event. But let's say you travel to an unknown location or a place you haven't been before. You know, you're on different networks. Maybe you're asking to transfer money to a person or an amount that's unusual in that case that should require some sort of additional authentication or authorization procedure to allow that to take place.
And then lastly, looking at the different options, you know, there's a wide variety of authenticators out there today, everything from password and, and KBA security questions, social logins, and, you know, things like smart cards and USB keys. But I think it's highly unlikely that outside the case of maybe very high value customers, banks are not gonna be issuing smart guards to customers for normal authentication. So most suitable for PST two comes down to things like biometrics, hopefully more on the Iris side, fingerprint is still good and then mobile apps. And again, this is a good, a good place where, you know, phyto protocols can be used to facilitate that. And with that, I'd like to turn it over to Alan.
Thank you, John. So I will complete what John has just said with a little bit more detail on the, the compliance aspects and in particular with the regulatory technical standards. And then I will explain how photo authentication can help actually on this compliance side. So I won't repeat what John said. So you'll know about the multifactor authentication. I just like to highlight what is in red here with regards to the procession factor in the, in the regulatory technical stands, it says that the device that you have should not be reusable by unauthorized parties. In other words, if you lose your device, the person who finds it should not be able to use it. It also says that proof of possession should not be replicable. And, and so when you look into these two requirements, you may come to the conclusion that for a user, for a person that finds a device or steals the device in order for this device, not to be usable, the genuine user will probably have to verify itself to the device, for example, by entering a pin code, or maybe by scanning a fingerprint. So there is this connotation of user verification, very closely tied to the possession factor actually. And the other aspect is that having a device and, and proving to a distance server that you have this device in a non replicable way probably involves the use of cryptography and, and the, the sending of cryptograms over the network. And I'll come back to this.
So one of these important requirements in the RTS when it comes to remote payments is this notion of dynamic linking that I'm sure you've heard about in essence dynamic linking means that after authentication, somehow a component in the system must produce an authentication code, which cryptographically links the, the user to the transaction amount and the, the payee and the merchant identification. In other words, and when you read the text, you see a lot of requirements that point to what you see is what you sign, even though it's not explicitly requested. So it kind of makes sense. Okay. And so the illustration here is that a way of doing this is indeed on the mobile phone, where a mobile phone has the ability to display the text and display the transactional amount and the pay and provide you with the ability to provide content important notion in PSD two and provide and authenticate to confirm.
Okay. And so signing what you see on the screen even though is not a requirement is definitely something that is, I think, in, in the scope of PSD two, I will not talk about exemptions because John did that very well confide and integrate integrity of credentials. This is again a requirement in the RTS. And so, so what it means is you have to secure, you know, the credentials that identify you to the server in essence. But the questions that are interesting is where are these security credentials stored? And so when you want to implement PSD two, you need to think about this. For example, are you going to store a password on the server? Are you going to verify OTPs on a server, or are you going to do verifications on the customer device? For example, you going to verify a pin, or are you going to verify a biometric or are you going to do a mix of both?
For example, touch ID plus OTP by SMS is a mix of both touch ID is local verification on the device of your fingerprint. OTP by SMS is an online verification of the procession factor. If you don't do things locally, you get into, how do I transmit things securely, for example, the password. Okay, so you get into, if you dig into these questions, it becomes interesting because if you need to secure a password, when you send it online, it needs to be encrypted. And so you get into key management, you get into interesting considerations. And again, this question, which is how do you prove that the device is in the hands of just genuine user, which I've already addressed. And so you may consider when you look at, you know, how you're going to implement PSD two for your own customers, you may consider solutions that combine user verification with proof of possession.
We talked a lot about biometrics. There's a specific aspect with biometrics that you must be aware of, which is the GDPR with the general data protection regulation. Because as you very well know, biometrics are very convenient, but they're not replaceable. You only have 10 figures and you only have one face. So if those are compromised, then you're stuck. And this is one of the reasons why GDPR classifies biometrics in the special category of data, for which actually GDPR forbids any kind of processing. It is forbidden to process biometrics, except so there is an exemption which is written here. That's from the GDPR regulation, that if, if biometrics are processed by a person on his own device, in the course of a household activity and so on, so forth. In other words, if you use biometrics on a smartphone where the, the biometrics are stored on the phone and never sent remotely or accessible outside of the phone, and if the matching is done on the phone, you are in the exemption. Fortunately. So just to bear in mind that if you wanted to do online verification of biometrics for PSD, two compliance, you get into difficulties with regards to GDPR compliance.
The RTS also have several articles around these security credentials and their management, basically the life cycle of these security credentials. So this all in essence, all this has to be done securely. I'll come back to that. When I talk about Fido, this is interesting. So it is explicitly said in the RTS, that security measures for the application of strong customer authentication must be documented and audited periodically by independent auditors. This is very interesting because when you look at how things are are happening, now this, this, this requirement is creating difficulties because there is no pan-European specification for what SCA should be. The RTS are not sufficiently precise. There is no pan-European wide certification body that puts a stamp on an SCA implementation. There are some that do in Germany. There is a body that provides some kind of certification in card schemes, card schemes, whether they're international or domestic card schemes have a certification program, but there is still this big risk of fragmentation because of this absence of a pan European certification program for PSD two. And so this is very important and, and pH can provide actually a solution to that.
Another requirement in the RTS that has caused a lot of turmoil for those of you been following PSD two in the past couple of years, is this notion of obstacle in this in famous article 32 without three, it says to make it simple that banks should not make it complicated for third party providers for the use of, for the customer journey. Let's put it that way. And it is true that with the introduction of TPPs third party providers, that, and, and so the user starts the user journey. Typically on a TPP application, it will end the journey on the TPP can application, but in the middle, it has to be authenticated by the bang. And by the way, it has to be authenticated with a device. And so this introduce, it introduces multiple interactions, which can make the life of the user pretty miserable. And I'll show you examples of that. And so the, the regulator says it should be easy, and that creates a lot of questions and potential difficulties.
So now let's look at how Fido can help with all these challenges, Fido fast identity online. It's an Alliance of quite a lot of companies that focuses on creating authentication standards. That's what we do. This shows you you'll find this in the slides, the board members of the Fido Alliance, a mix of, of big companies in consumer electronics and operating systems of security and biometric companies and service providers, including including banks and, and payment service providers and card schemes. So pretty broad spectrum of, of companies in the fi Alliance, the Fido standards, there's this, the very first one was the universal authentication framework or Fido UAF, which you find very much in mobile phones. The SDK that that John was mentioning is often a UAF based SDK. And more recently you saw the announcement, the fi oh two standard, which brings native support for Fido in web browsers, but also in platforms in windows 10 and in Android seven and, and further.
And so what that means is that in the browsers, in the, the latest provisions of all these browsers, including safari, by the way now was recent amount of apple that Fido APIs are available. They're called web and APIs, and they were actually specified by the w three C. So this is joint collaboration of Fido and the W3C for the creation of these web and APIs C a is a communication protocol between these platforms and external device like us keys or, or smartphones very briefly. This is the way fi works. It's a two-step authentication, there's first a local user verification. So you enter your pin or you scan a biometric or, or a selfie. And this, the pin or the biometric is verified locally by the device, which is in the middle. That's the authenticator, that's the first step local user verification by the device itself, the device, the authenticator stores, a private key, and this local user verification step unlocks the use of this private key so that a distance server can send a message to the authenticator.
And the authenticator will provide a signed response using a, a signature generated by the private key. That's the online authentication step. And the, the server, the service provider on the other side has a corresponding public key to verify this signed response. That's very briefly how fi works. What is interesting is when you compare the way fighter works and the requirements in the RTF on the PSD two, and you see that a lot of requirements have a direct correspondence in Fido. For example, these elements of authentication, well, you find them in Fido. It's the pin, it's the biometric data, the security credentials defined in the RTS. That's the Fido private key. The authenticator of Fido is the procession element under PSD two. When you look at the, this notion of authentication code, which is very important in PSD two, the authentication code is the signed response of Fido and actually the dynamic linking requirement, which is this authentication code that signs the transaction amount in PE is supported by Fido.
Fido can sign an incoming message, which may consist of in particular, the transaction amount and pay. And so this signed response is an authentication code with dynamic linking. And here is interesting to see also that Fido provides a response to these questions around how do you ensure that the local user verification was done properly? You know, how do you, if you verify your biometric on your phone, how does this server know? So you could say, yes, it's done. That's not enough. And it's not secure here with Fido. The positive verification on the device of a biometric is contained in the sign response generated by the authenticator. And so by verifying this signed response, the service provider, the relying party actually verifies both the procession of the device materialized by the private key and the correct local verification of the pin code or of the biometric by biometric data.
I will skip through this, secure it in privacy is at the heart of everything in Fido. And so it's, it's very easily seen in the fact that in Fido, there's no shared secrets. It's based on public key cryptography. The private key is in the device, generated in the device and never seen elsewhere. Public key is uploaded to the server. Public key is not the private key. If you find the public key, you do not, you cannot derive the private key. So there's no shed secrets, the user verification stuff, whether pin or biometric never leaves the device. And so that's, that helps with privacy. There is, and here we would get into technical details there ares in Fido to prevent against man in the middle text, there is no need in pH authenticators to have user information, just the private key. If you find a Fido device, you do not know to whom it belongs. So there is no linkability between the services that a phyto device provides access to and the actual user. So privacy is a very important aspect of phyto.
Phyto of course, supports biometrics in the way that meets the GDPR exemption. Okay. So it's yeah. Local verification of biometrics. But what is interesting also is that a Fido server does not need to know how the biometric verification was implemented. It is independent. And so a user could have a photo authenticator embedded in their PC, in which case, for example, because phyto is, is now embedded in windows. Hello. So face recognition provided by windows. Hello would be proof of local user verification resulting in an online authentication by the server. But that same server would be able also to do exactly the same with a fingerprint verification of that user on a mobile phone. So the interoperability offered by the standards also provides this benefit that there is no linkability whatsoever with the type of biome modality used Fido greatly facilitates the security credential management. Why, because you do not create credentials in somewhere and, and deliver the credentials to the device they're generated within the device. Private keys are generated within a photo authenticator. They're never provisioned to photo authenticator. And so it simplifies greatly all these requirements about creation and delivery and renewal of credentials. And from a destruction revocation perspective, this can be handled very easily on the service side. You just, you know, flag the corresponding public key is revoked, and that defacto forbids the use of a private key in the authenticator.
Fido comes with a certification program. You can, you can certify a Fido device, both from a functional and a security perspective. There's a complete security evaluation in the Fido certification program with various security levels, which I don't have time to detail, but it's interesting because Fido provides an independent program to certify against security requirements, which are perfectly in line with those of PSD two and the RTS. And so this is an effort that we are doing currently with the Fido Europe working group. We've written a white paper actually on the, the compliance of Fido authentication with the RTS. And that can be attested by a certification delivered by the fi Alliance. And so banks interested in fi authentication can make sure that the vendor from whom they purchase fi solutions have the proper level of security certification. It's a real benefit because this is or can be pan-European, it's not linked to a particular country or, you know, or a particular certification lab.
It is an independent worldwide, as a matter of fact, worldwide certification program. So could, can be very well be put in place by, whoever's gonna define a certification for PSD two in Europe to finish on this, this obstacle aspect, which is very critical in PSD. Two is critical because if strong customer authentication is simply too complicated to use, it will be very detrimental to a successful deployment of PSD two. So this is really the key in the user journey. And so when you look at it, there are a number of authentication models that can be implemented. First redirection. That is to say, I'm on a PC or I'm on a phone, I'm in a TPP user interface at the time and need to authenticate. I am redirected to a bank interface here. I, I authenticate so on a PC or on the phone, if it's app to app and one that is done, I'm redirected back to the TPP user interface. That's the redirection. Now decoupled is a variant of that, where I'm on a device, for example, a PC. And when I need to authenticate my other device, for example, my mobile phone wakes up. I see that I have to authenticate. I authenticate with the bank. And once that is done, I continue my user journey on the merchant user interface. That's called a decoupled it's it's to make it simple and out of band model.
And so this seems pretty straightforward, the bank authenticates, but they have potential issues with this. And this is an example. I am a user with a TPP, which is an account aggregator, and I have three different accounts, and I want to authenticate with my three different banks and my banks. Unfortunately, they have different means of authentication. The first bank uses a mobile phone, the second bank in a decoupled way. The second bank uses SBT. And my third bank actually, they're, they're on OTP. They have this piece of hardware used to generate an OTP. Okay? And so my user journey is redirected to my mobile phone. Then on the start is done properly. I'm redirected to a bank interface and I have to stick in my SB key. And then once that is done, I'm redirected a third time to my third bank. And here I have to draw my OTP generator out of my pocket, punch in a pin code and generate an OTP. And at the end of all of that, I've succeeded in gaining access to my accounts. And this is a major issue with all the account aggregators in Europe, major issue.
Another example of a potential issue is for payment. If this redirection model is not done properly, you could end up in a journey like this. I click on a button, which is a payment initiator button. I select a bank and I'm redirected to this bank. I log in and to my password, that's my first factor. Then I have to select the account with which I have to pay. Then I have to provide my content. Then I need to receive or generate an OTP on a device, for example, a mobile phone. And then I have to enter this OTP in the user interface of the bank. And once all that is done, I have paid. And in remote payments, every additional click is a chance to abandon the transaction. So this is also, if this did happen, it would be perhaps considered as an obstacle to the provisioning of TPP services, perhaps.
And so here, the message of Fido is that Fido can make it very simple because to make it simple, Fido is a one click or one, one step authentication. If you will, especially in this decoupled mode, you click on a button, your phone wakes up, you see the details you put your finger, you have paid, it's done. It's very simple versus also SMS OTPs, for example, is necessarily a three step authentication because you have to enter a password. You've gotta grab your device. You've gotta enter the OTP. It's it's minimum three steps. There are other models, which I don't have time to, to explain or where the user interface is at all times in the, with the TPP, you never leave the TPP user interface. And these are the embedded model. And the other one is called the delegated model. And so Fido has worked on this.
There impacts these two additional models, both technically, and from an agreement perspective, for example, in the embedded model, you, you stay on the TPP interface, but you're authenticated by the bank. And therefore through the open APIs, you have to handle authentication data, but Fido provides for a mechanism to implement the embedded model. And another one is delegated delegated model means that the TPP in this case authenticates the user rather than the bank, but still you have as a TPP to prove to the bank that you've done the job and that you've done the job in a proper way. And so you need to communicate through the APIs, how authentication was done. This again is a model that Fido has worked on and Fido is, is interfacing with the building group, for example, or with St in France on the implementation of such models. And that concludes what I wanted to present to you today, back to you.
Great. Well, thank you, Alan is very informative. So now we can move to the Q and a part of the webinar. And the first question that we have is where can phyto authenticators be found and in what form factor?
So phyto authenticators can be found. So for example, in mobile phones, I mentioned about the UAF standards. So there's quite a lot of vendors that provide SDKs based on the pH UAS standard. And so if you wanted to implement the bank in your mobile banking app, Fido authentication, you could use an SDK of that kind, but now with Fido two, it also goes beyond that because as I said, Fido is, is embedded in windows 10 and Android seven. What does that mean? It means that provided you have your deck adequate phone. Obviously the operating system provides with native APIs to implement Fido. So in windows 10 PCs with if, if your windows phone, if sorry, if you, if you PC has a TPM, for example, which is a kind of trusted execution environment in the PC, then some PCs offer pH authentication natively in windows 10. And we find the same in, in Android phones. It comes natively. And so more and more, you will find pH devices in the field already, if you will, but you find otherwise implementations and USB keys, or you find implementations in mouses. So there's so mouse, a mouse connected to a PC. Sometimes you find mouses that have a biometric scanner fingerprint scanner on the mouse, and they are Fido, phyto enabled. So variety of devices.
Yeah. That certainly makes it easier for users. Next question is which biometric modalities are currently supported by Fido.
So that question is more, is vendor dependent. So mostly on mobile phones, by the way, even though with the example of the mouse that I just gave you find fingerprint or the modality, you do find some vendors that propose face recognition on Samsung phones. You have vendors including Samsung themselves, by the way, proposing Iris scan as a modality embedded in Fido. I do not know if there is voice recognition as yet, perhaps, but as I said, fi O is independent on of the, the modality, which is used,
Right? Yeah. I think I know of some vendors that, that actually do voice. They, they kind have a suite of biometric modalities that are supported in their apps. And you can, as an administrator choose either equivalents between say fingerprint and, and selfie, or, you know, rate them, you know, one higher than another so that you can develop authentication policies that match what your organization requires. But yeah, out of all the different biometric modalities that I was talking about, I believe that there are phyto authenticators for them. Last question I see for now is, is phyto certification recognized as a valid PSD two certification.
So, yeah, so coming back to that, so again, as I said, unfortunately, there is no identified body in Europe that is tasked with saying this SSEA implementation, complies that SCA implementation. It doesn't exist. It's, it's actually it's missing in a way. And so I know that some labs or, or some consulting firms have taken the initiative to like SRC, for example, in Germany, they've taken the initiative to say, I will propose services to banks to, to, to tell them whether they're ACA solution complies with the requirements of the RTS, but it's, it's the kind of individual initiative, if you will. There's no pan European body, that's the problem. And so that's where again, there is this risk of this is a risk for vendors, by the way, because of the cost of going through multiple certifications. You know, if there's one per country, it's hell on earth, right? And so this is where we find Fido is potentially attractive. If Fido is recognized by, you know, different countries as satisfactory and compliant way to, to authenticate under, under PSD two. But it's, it's hard to answer the question now, because this is a gap I believe it's missing in the regulation, that there is no identified body to, which has the task of delivering a stamp on FDA implementations. It's not defined
Well, you know, that's one reason I started off with the first slide about, you know, this is a directive rather than regulation, you know, in many ways, I mean, I'm not in Europe, but you can probably comment on this better. A but I mean, it seems like a weaker implementation. And, and to me it was not that big of a surprise, I guess, that some countries are sliding their enforcement dates for both the PST two SCA side, as well as I I've heard some, you know, many, quite a few banks are still done fully ready on the API openness. So, you know, that lack of centralized administration, pan-European certification board for saying what counts as SCA and what doesn't. I think that actually is kind of hindering the, the final uptake here. Would you agree with that?
Well, possibly because there is, there's a lot of uncertainty, for example, around SMS OTPs. And so the EBA has tried to clarify what is, and what is not satisfactory means of authentication. For example, they did say that OTP by SNS is considered as a compliant means verifying the procession factor, but it's stretching it a little bit. When you look at the other requirements, for example, you must provide for remote payments. You must provide to the user, the details on the transaction, the minimum being the amount and the pay so that you get content, right? And so by with an SM OTP implementation, that means that you send this information to the user by SMS, but actually the requirements of the RTS on how this information is sent to the user, it says, you know, it should be protected, confidentiality, integrity, all that is in the RTS, but can you really, you know, is, is SMS a good channel to ensure integrity and confidentiality information? I'm not sure. Yeah. And so theba probably under the pressure of banks because SMS OTP is exists and it has qualities, you know, it scales very easily, you know, so there are qualities linked to SMS OTPs, but from a strictly, from a compliance perspective, there is a big question, mark. In my opinion,
We have another question here are transaction confirmations, a mandatory or optional feature in fi oh two.
I'm sorry. Can you repeat,
Are transaction confirmations a mandatory or optional feature in phyto two?
Yeah. Okay, understood. So this is linked to the, to the dynamic linking requirement. So transaction confirmation is Fido notion. It it's, it means that the information is displayed to the user and it is signed by the authenticator. That's the notion of transaction confirmation, which is indeed a feature of pH UAF. So a vendor providing a pH UAF SDK can, if he implements fully specification propose transaction confirmation, which is again, this notion of dynamic linking. So in other words, this, the information is displayed on the screen of the phone, and then it is signed by the pH authenticator. Of course, this is very linked to the, the authenticator itself. If for example, you choose a USB key inserted in a PC. The USB key does not have the capability of displaying the information, but it still has the capability of signing. However, okay. And so here again, the, the RTS do not explicitly mandate. What you see is what you signed. It says that you should provide to the user, the information, and somehow an authentication with code with dynamic linking should be generated. And so Fido is capable of doing that even with USB keys.
Great. Well, thanks, Alan. We've run outta questions in we've run outta time. So good ending to good webinar. Thank you for your participation and your content, and thanks to everyone who has attended and for the questions that were submitted, like we said, we have recorded this. We will make the recording and the slide decks available tomorrow. And with that, we will conclude and have a good day.
Thank you. Thank you. Bye-bye.