And here you can see my picture and the conduct information. Like I said, I'm working for the national cyber security center and in the supervisory position and doing the supervis supervision to strong authentication services and trust services here in Finland. The correct, let's say thing here now is talk about the strong authentication services. And the story goes that we had something legacy and now we have something that is so standards, which is future proof. And we'll go through the process and the history and the lessons learned from that experience.
And you can look up the conduct information afterwards from the slides. We can go forward, please for you to better understand how things happened. Let's take a look at the little bit of the history in the late nineties, the finish and most of the Nordic bank started to issue strong authentication means to their customers and the web banks started to get more and more popular.
So they started to hand out onetime password lists, printed lists to their customers to enable them to more securely log onto the banking services.
And at the same time, BHA here in Finland had an idea that maybe we should sell these authentication transactions to third parties. And in 2003, three major government organizations, social security, employment, and tax decided to adopt this approach. And they actually started buying strong authentication services from the private sector and long story short right now, for example, public services are using this kind of strong, strong authentication to their services.
We have an E I D that is issued by the government, but it's not really used in the authentication for practically anything it's sometimes more frequently used in the trust services, which means electronic signatures. And this whole thing, we call the finish trust network and it consists of 10 banks, some of them local, and some of them are international and three mobile network operators that issue their own identities in turn, in the form of a mobile identity, PK, best bomb identity.
And from the relying per relying party perspective, it was kind of challenging because as you see in the picture, if you are a relying party, you have to do the technical integration and commercial negotiations with all 10 different banks and due to the roaming facility of the MNOs mobile network operators, you had to only do this exercise once for the mobile ID, but it was really hard. So let's move on next slide.
And not only was difficult, it was also expensive because there was kind of a lack of competition in the market.
The banks had a dominant position from the start and kind like if you wanted to have strong application to relying party or online services, you had to go to the banks. And then also to the mobile network operators, if you wanted to cover the whole population of Finland, let's say from the age 15 to upwards, and the difficulty was the technical and commercial thing, but it's also a legacy system that meant that in time it became insecure. And these are the main challenges that were present in the legacy system. And the legacy system used a, an in house built or home bank protocol called TOPA.
And that was the, let's say the child of the nineties. So let's move forward.
These are some of the things that happened during the past 10 plus years. And there are some relevant points like came into effect and we made a national law and regulation that adopted and further define some of the aspects of I to the national scheme. Then we had PSD two that was driving the banks to adopt new authenticated, authenticators or authentication means. And due to the 2016 law, they had to stop offering the legacy protocol and legacy implementation of strong authentication to third parties in 2019.
And that was the end of legacy. That was roughly a bit more than a year ago. And we are also now updating our new regulation for the, for the strong authentication and trust services. We can move forward.
What happened? Thanks to the regulation. We introduced a, a broker model into the finished trust network. And the broker model means that it's easier for the online services to adopt and buy strong authentication services from the private market.
For the, you know, if the reliant party is public or private, it doesn't matter. They are still buying these from the private sector entities. We define wholesale wholesale price, meaning that if you are an identity issue and you are selling these identity attract transactions to a broker, there's a ceiling for the price. And that was, that is right now three Euro cents. And you can't go about that. The brokers that deliver this authentication to the online services taken price, their services freely, and we also modified the security requirements and that changed quite a few things.
Competition opened up and it's now way less expensive and easier for the online services to adopt the strong authentication into those services. So we are seeing quite nice growth in numbers next, slightly.
And here you can see that, well, there are still the 10 banks. There are still the mobile network operators that brokers are making it much more easier for the online services to adopt. So it's one agreement and one technical integration let's move forward. And we are kind of strict in our regulation.
We actually define crypto suits and these kind of things in the regulation, but it was up to the market to decide what they wanted to use when giving up the legacy protocol and almost all of them chose open ID connect. One of you one or two are still doing SAML, but they are within inside the finished trust network. And they are not, the SAML interface is not available to the online services. So all online services that require or need strong, strong authentication, they use of connect.
And one of the most important things is that since 2016, if you want to offer a strong education to finish online services that deliver, let's say identities of people that are, that have finished social security number, you have to be, you have to notify us and you have to go through a security assessment every two years.
And we also publish quite a bit of regulation guidelines. And if you are looking for a guideline or an assessment criteria on how to evaluate security of a identification system as a whole, there's the long link in the bottom of my presentation, we can move forward.
And the extent of the regulation is here. So we regulate issuers of issuers of identity.
We, they also are in contact with author sources like population registers. We regulate the brokers. We regulate the authentication means and some aspects concerning relying parties.
So we, we want to make sure, absolutely make sure that confidentiality and the integrity of the authentication messages stay intact through the whole process we can move forward. So did we learn anything during this process, which was kind of lengthy, but then again, quite a bit of things happened at the same time in a short period of time.
So yeah, let's move forward.
A couple of things that were will obvious Sam London, opend connect, trust frameworks are different. And one thing that is bothering us right now is that TLS is not enough. And I'll come to that in the latest slides let's move forward. The things that we learned, well, regulation opened up a stagnated market surprise, surprise, but it happened. And from the regulatory perspective, you need to involve wealth stakeholders, so, and different roles from the stakeholders when you are doing, when you are crafting laws or regulations.
So law make a legal aspect, commercial, technical, and also resilience. One thing to know that if you invite technical people to channel on meetings where legal aspects are talked or vice versa, interesting conversation may happen. So lesson learned, try to keep them separate. And if you don't, if you're not careful when crafting the regulation for the national scheme, you may end up in a difficult situation. Next slide please.
So for example, our regulation called M 75 dictates that we use certain kind of crude suits to protect the data in transit.
So we made it too strict, which meant that new protocol, new suits like Chacha and poly, and these kind of things were not allowed bad for us. And when we, we were creating the text for the first version of the regulation, Sam seem to be the predominant technology, and some of the wordings are reflecting that, and that's kind of a oops situation.
And we have to do now some level of interpretation of the regulation and well, the finished trust network is a combination of identity, issuers and brokers, and that's kind of a set and they, that doesn't change quite that much, but there's say thousands of relying parties. And in, in certain terms, some security requirements that we make may not be effective or really hard to follow from the reliant per perspective. And one thing that was really important is how do we bootstrap the trust?
Because we don't want anyone to join this network as a reliant party, because we are delivering strong dedication. And that means that you can do quite a bit with these identities. For example, you can buy or sell a property. If it's depth free using just this identity and your health in key, you can sell a property way more worth than 1 million euros just online using this identity. So pretty careful let's move forward.
This is perhaps to technical, but still it's something that we are now considering, but this is a lesson learned for us for, so for example, old open ID connect core specifications are in the red and they are not enough for us. And the key here is that we want to protect the personal data in transit. So when they are traveling, when the messages and until can start traveling through the net, that they don't get decrypted in wrong SIS or that the data just leaks somewhere else. So we have looked at what's available and there's gonna be a copy presentation, I think next to this one.
And we found out that some of the things that are out there will, we have to do a fair bit of combinations to really make sure that the data stays safe, give this to your technical guys and see if they make any sense out of this. Let's move to the next slide.
And what we found out also from the regulatory perspective is that the recommendation is a recommendation. So we have recommendations for open profiles and sample profiles. They became major challenges in testing, for example.
And one good example is that one test set that, that he had to work the main down the main street and go to each and every bank office and create an account and get the authenticator so they could actually test the integration. So that's not good integration when they use recommendations. It's not really the same as using the exact same profile. So profiles may differ and in the integration, there's a lot work to be done updates right now because key management is an issue for us. Sometimes there are service outtake outages due to the fact that they haven't updated their keys.
And when you are considering the whole country and how things work, you are working a MultiPro multiprovider ecosystems.
It things like binding messages, so that if you have an authentication app in your phone, and you are looking at the browser, you get the binding message, which can be for example, five letters that you can compare those. So you can make assumption that yes, I'm authentication authenticating to this particular browser session. Or if you have brokers in between, then you have to inform the user that where are you actually going?
We have had cases where users have been SPOD to you to authenticate to a, let's say a broad site. And if you have a multiprovider ecosystems handling errors in a uniform way is also very important and it's not here, but it's not, it's not implemented yet. But I thought from the technical perspective, that single sign would be easy. Technically it is. But in this situation where you have 10 banks, three mobile network operators, brokers, and relying parties, it's not, it's a question of liabilities and let's say responsibilities and who controls the single sign on session and so forth.
And it's also confusing to the end user because they have learned that they have to authenticate each and every time when they move to a different service. But these are some of the lessons that we have learned during the time that we switch from a legacy protocol to open ID connect mostly, and some Sam as well. And I think that's it.
