Thanks for interaction. I am NA senior research, well actually research fellow Nu research Institute, as well as having the chairman of the board of the open I foundation since 2011. So it's been quite a bit of time and I was making this journey all the way through, you know, for the last 25 years. So I thought that it was a kind of good timing to look back and assess what we are here, where we are and look into the future. So identity management has never existed in vacuum. It always had purposes such as to be the key to the treasure key to the resource. In case of the 40 THS in with, in the Alibaba and 40 THS, they were using open Sesame as the key. That's an example of a long term, weak share key. Now we, in the identity landscape, we all know that this is a very bad idea, and we know what happened to those 40 Fs.
Rome did slightly better than that. They were still using shared week symmetry key, but they were rotating it daily with AC based key delivery protocol to multiple locations, which is really ingenious. You know, they were doing 2000 years ago and no wonder they built a, you know, such big empire when it comes to digital identity, it's probably MIT's CTS system. Back in 1961 was the first instance of using log in the password. It's an example of individual password and individual digital identity, which resulted in past system identity. Now I use the word identity delivery instead of password. The modern definition of identity is set for attributes related to password is one attribute. But when we are authenticating user, we can use other attributes like biometrics and so on and so forth as well. And this definition actually comes from what is called entity identity model.
In real, in reality, we don't perceive entity directly, but through the decomposition into attributes, right, we see her, we don't perceive her existence directly, but see her face, her voice, how he, she calls herself and so on so forth. And the iden entity doesn't have to be a human being, but if it happens to be a living human being, this identity becomes personal there. And this model is very convenient when we are talking about privacy, but I don't have time to get into that maybe next time. So how do we get that identity into the information systems obvious right through the authentication entity provides claims like username, password, your location, device information, so on and so off then authentication server verifies that against the, the values stored or calculated from what is in the identity register. And if they match in the factory degree, then authentication, succeeds, and authentication. SVA actually creates something called authenticated identity with attributes or claims that it can test needless say for that kind of thing to work identity registers. I mean, the, the attributes or claims in the identity register has been managed very, very secure and consciously. And that process is called identity management. And the picture here was take taken from 20 ISO 24, 7 60 identity management frameworks.
So we have authenticated identity if there was only one system that's okay, but in the network computing age, we are now having Mar many services to interact with. And we end up with many identities. It's fine from the point of view of the privacy, because then, you know, if we have something like that, it will become very difficult to track and correlate. But think of the case, one service, one service two is using the exactly same identity. Then it's plain wasteful. And to cope with that kind of situation, shared identity model came up. You know, we still use that often ELD up is one example of such such thing, but there's one problem with this what's that fishing in this case service one service two is using the same password, right? And the service one can receive the password, the, and replay it against service two to impersonate the user. So this can be a problem, especially in the context of multiple services, spreading multiple domains. The one of the obvious way to solve it is to bring that identity, register to the front end and call it IDP. And now you provide password and so on to IDP. And in return you get ID token and these ID token audience restricted to each services. So service one is getting ID token that is minted to service one, and it cannot replace against service two. This is called federated identity.
And one of the early example of web based federated identities, some one oh, that came in 2002, which evolved into some 2.0 on, which was based on XML, XML, DC. And so in 2005, independent of that open 90 authentication, 1.0, came out in 2006, which quickly evolved into authentication 2.0, which was using key value. You know, the main author was David recording. And in the same year, later earth, 1.0, came out in the same year. We had a very important event in the information, the industry or information system iPhone, right? It came up in 2007 and in subsequent year, arguably more important event happened. The interaction of app store and app store existed. Suddenly we are faced with gazillion of untrusted apps, which wanted to get password and to ask, you know, to know the identity of the user as well as to access the APIs. Is it good idea to give password that means full right to all of them? Obviously not. That's a very bad idea. What we should be doing is to give audience identity and minimum access authorization, which translated later into ID token and access token, by the way. So we needed to build something that achieved this and the obvious candidate to build on that, build that on was some or open ID authentication to or one oh, but they all shared same problem,
Bri signature system. It was caused by canonization.
So me and John Bradley and Breo Maderas from Google sat down together at I a w and started sketching out. What is the provide design for the new protocol? First two was no can no can equalization and ask the armoring. This was to deal with the Britain loss of the existing signature system. And then we also asked through the interview through bunch of developers and they positively hated XML. And so, and they wanted to have Jason the rest. So they came as the design decisions as well, but that meant we had to device a new signature system. So we developed Jason's simple signature and encryption parallel to that, to a gentleman from Google dark be fonts. And John pan was working on very similar thing. It was called magic signature and Jason token. And then, you know, looking at that Mike Jones, who is down just here, came down and told us, you guys should come together and standardize it at I ETF initial reaction that I had was to push it back because it, I know that was a lot of work, but then he said, don't worry.
I can take care of the editing and all the, you know, political stuff. So we said, okay, go ahead. And he took the editorship and result in JF X. It was not as simple as Mike told us in the beginning, but there we were. So we had J w X, but we still had to decide on what kind of transfer, you know, transport mechanism that we are going to use, or one O was an obvious candidate, but it had unnecessary overhead baggage of Canon equalization and symmetry based signature system, which we didn't want to use. So we are almost at the edge of creating our own, but at that point, these two gentlemen came up with something called or wrap, which removed all those baggage.
We jumped onto it and we started using that. And by the way of rap later become or two oh, so or two oh, was standardized in 2012. And in 2014, after multiple brands of interrupt, interrupt, testing, openly connect, which was based, based on Jason J and rest was published. The resulting protocol was modular, layered protocol that defines for a client how to request and for the server to provide the ID token, that's perfectly fit for modern identity and access control frameworks. Well, I have depicted it here is the AAC system, but, you know, we had this in mind from the beginning. It's got a great traction as of last April, over 90% of Azure ad app authentication over open connect, which is good, but this is just the beginning. Open 90 connect is a big specification. What is being used right now are the part that our marketing yellow here and there are open idea. Connect has a lot more to offer. For example, section six, passing request parameters, as JWT combined with section three to three, three can deliver multiple signature mutual signature protocol, which was conceived as a mechanism to achieve contract exchange, which actually was the original use case for open I connect.
It was a quite unpopular feature during the drafting. People said that it's too complex and nobody's going to use it. Maybe that's true for social sharing kind of use case. But what about in the case of entering a binding contractual relationship like payment, obviously we need that, right. And so it's now being used as the foundation of open ID, financial grade API FPI security profile. And it's being used by UK banks. Another feature which I'm looking forward to come to life is a self issued provider. That's section seven, open ID is a protocol. It can have various deploy deployment patterns, father party, hosted identity, such as social or banking identity is one deployment pattern, but it doesn't have to be like that. You can host your own IDP on premise on cloud. In fact, I have been hosting that for many years, but that's for the geeks.
And for most people, it's probably easier to do it on their phone, right. And selfishly open ID provider is describing how to do that, right? But it's got challenge, right? Establishing, trusting keys using past is one thing. And key recovery is another thing, but they can be picked out. One of the most ticking problem is that RP are not accepting it. Hopefully the movement of the, you know, self-sovereign identity would solve it, but it's yet to be seen, but that, that can be achieved through open ID, connect discovery and dynamic registration. And then reg, I can kind of understand why those people don't want accept these, you know, self hosted IDPs, because that's because of the potential support cost, but self certification that we are hosting at open ID foundation can probably help that as well. So discovery and dynamic registration, dynamic registration combined with openly connect core can also do amazing thing like granular claims request and consent management and claims request model are specified five, five.
I'm not going into detail, but we have already specified policy and to, and so on. So forth and combining with, you know, three, one or two, we can achieve the selective sharing system and of which you can always revoke the consent by just, you know, using regular or mechanism. And there are three claims model in openly connect, normal aggregated, distributed normal it's, you know, one IDP provides claims to the client directly, but aggregated is taken from other health parties, which are signed so they can be verified and, or the IDP can just provide that the, the reference to the place where the client can get that claims. So that's it. And an example of ongoing activities on the claims set is minimal viable E KYC framework, which is worked on in European commission right now, other consent management initiatives. So trusted personal data management service is something that I'm working in with Japanese government.
And it's trying to give ethical assistance to control over consenting, you know, individuals that notoriously bad at not giving consent when they shouldn't. And then there was an ISO study period and consent receipt, which you you've had about consent receipt multiple times. And it's probably going to be standardized in ISO. And then there are also online a education for flying a education scenarios, like, you know, in the case of call center or where, you know, instead of doing KBA, you are going to be pushed a notification so that you can authenticate to using your phone. And that same mechanism can be used for smart speakers or at the post time.
Right? So here's a project landscape, we've got the of open ID connect using FPI. And so on, by the way, FPI is formally proved to be secure. So it's Futureproof so please have a look at that. So it can be used in even high security kind of areas. And then, you know, we are looking forward to get E K Y C kind of stuff using claims model. Obviously we have to think about key management and potentially that can be done with blockchain. I haven't touched on it in today's talk, but, you know, combining something like fighter, we should be doing something like continuous authentication and risk information sharing. And last but not least concept management system are actually coming. And many of those work are done within open foundation. So please come join us and together let's form the future. Thanks very much. Thank you. Thank.
