 Okay, let's start it. Everybody hear me? Yeah, very good. Okay, I was already originally starting this, ladies and gentlemen. But maybe, okay, ladies and gentlemen. Welcome and thank you for coming. Nice to see so many of you here. Hopefully someone else will still come. Today we will give you a short talk about our long-lasting research project in the area of self-sore and decentralized identifiers. Our topics today are who we are, what we have accomplished, live demo. And then we will show how it's done, a little bit deep dive into the architecture and technical details. Not in the code level, but something like that. And finally, where we are going next. And maybe if there's time left, some good way as well. We come from a Finnish bank, OP Financia Group. It's Finland's largest bank. And we work there in the innovation lab. It's for the emerging technologies and some research as well. It's changed during the time a little bit, but that is where we are. And about five, six years ago, first DLT project was started. And they were run in the area of real estate and stock exchange for non-listed stocks. And those blockchain experts, we are like different people now, but then in five, six years ago, they started to learn that decentralized identifiers could be something that would help a lot. And about three and a half years ago, we started to study the subject from the, I could say, pragmatic and performance centric angles. And what it means, the pragmatic means that we try to find any road blockers or even deal killers that would prevent us to go to the production as a bank. So, certain security issues and stuff like that were pretty important for us. And the angle we took about the actual project, I also, what differentiates our solutions from the most of the other SSI agent? What makes it different? And there is a very long history behind all of these decisions. We have tried a lot different approaches during the three and a half years. And we have used areas and indie for the libraries and for the specifications. I could say even that more of the specifications. And the trust triangle here is more for the illustration purpose. And we are not going to define the methods that did come or stuff like that in this presentation. We take them as a granted. But about our solution, it has been since the beginning in multi-tenant. So that's the agency model. And also all the agents are symmetric. They can be sewer, verifier or holder. It doesn't matter. Maybe before I go to the next step. Water, as I said, we have a multi-tenant agency with symmetric agent model. So we did learn, but we did very many POCs and use cases during this three year period. But we started to learn that we are not only building applications or even frameworks or libraries. But we think that we are building system software. And if you are doing that, you still need lots of lots of tools that you are able to maintain fast-based development cycles. So we say that we are building system software with batteries included. And we did select CRPC API technology mainly for two reasons. It gives us certain technology agnostis. It is technology agnostic and also allows us to be the, I could say, polyglot. That implementation and also clients can be written whatever language is appropriate for your case. We currently have pick up this approach that we have react-based web wallet, which is using Fido to Authenticators. And authorization model is based on Fido, Authenticators and also Jot tokens. We, even that we have taken these little bit different approaches, we are interoperable at the AIP 1.0 level and currently working for the 2.0. Our version can be used without the lecture. It means that we did learn that if you want to start something very fast, you want to start development very fast and even run some POC or some pilot, which still doesn't need or interoperable the capabilities, you could do it with even the database or something like that. And it's actually helped us a lot. So you are capable to run the system without the lecture. I could summarize that our solution or our architecture is cloud-centric with certain sovereign computing twist, that you can easily install it public cloud, what we have done and it can be seen in the demo, but you could install it in the black box in your home or whatever it's there. And later we will explain more about that. Next we will see Laura's demo and after that, as I said, a little bit more about how it's done. Yeah, hi all. My name is Laura and I'm Harry's colleague from OP as well. And let's see, I'm going to try to show you in the agency and in action. So live demo, exciting times. I'm going to use here the cloud installation of Fendi agency. I'm just going to find correct windows there. But I want to remind you that even though I'm showing you the instance that we are running in AWS currently, but all of this that I'm going to show you is open source. You can easily take them, the codes and the ready-built Docker images from GitHub and run all of this same stuff in your local host computer. And I recommend you to do so. So Fendi agency is a full package for developers who wish to implement applications that utilize credential in their flows. So we have, like Harry said, this web wallet application. Actually this React app that we have is kind of in a POC level, but it proves like the concept. So neither of us are proper front-end developers, so we are concentrating more on the back end. But anyways, I hope it demonstrates what we are aiming to accomplish. The web wallet is intended for the individual users who can then receive and prove credentials with the web wallet application. And then we have this extensive GRPC API, like Harry described, which is intended for any applications to manage and handle their cloud agent that is hosted by our agency in the back end. In addition to that, we have the CLI tool, which is also a handy tool for commanding your agent to do things that you wish. The agency is multi-tenant, so it can host several different agents at the same time. And it's quite convenient for the developer as you can start up one instance of agency to your local host computer and host all of the different parties that you are testing with. So you can have your issue up there and your verifier there and your individual users. So it's quite convenient. And as mentioned, we don't have a mobile application even though you could easily use the same approach that we are using in this React application, in a native application as well. So it's just like a static React application that is doing requests to the back end, and the back end is doing all the hard and dirty work related to the credential stuff. So it's just a basic React application which utilizes the browser capabilities for this authentication that you will going to see soon. Our name is Findi Agency, and that's a bit misleading because we have in Finland this Findi identity network, which is a national identity network project. We are not directly related to that project at all. We are a separate open source project, and you can take our software and run it with any indie ledger. It doesn't have to be the Findi ledger, so that's a misconception that we get a lot. We don't have the strength and energy to change all of those 30 repositories names, so we are Findi Agency now. And like said, we are hyper ledger areas compatible, so you can take ACAPI and Findi Agency, and they can talk together quite nicely. Okay, but the demo, I will show you how to allocate a cloud agent for the individual user and register a new user account, how we can then log in with that user, and then of course the other side, so I will show you how to issue and verify credentials. And that we will do with the basket that will utilize this CLI tool of ours, and actually we are going to run a simple chatbot, so we have this cool feature in the CLI tool that you can just write a bunch of YAML, definition, and the CLI tool will start up the chatbot for you, which can then utilize credentials in its dialogue flows. So we will see an example of that. Yeah, and the story, I'm sorry to disappoint you all, but we are going to meet Alice again, and again she's getting her degree from Faber and applying a job at ACME. But maybe in the next hyper lecture forum, global forum we will have new stories then. Okay, so here you can see my iPhone screen, which is connected to the computer, and the first thing that we are going to do is register a new account for Alice to allocate her a new cloud agent. And I have, this is Safari browser, so I have navigated to our cloud installation starting page, and there I can choose this register option and figure out a unique username that I forgot to do before. But let's try out if Alice.hyberleture works. And here when I tap the register button, what actually happens is that the React application uses this web-outen API in the browser and sends its request to our authentication server and does this FIDO to magic and actually binds our device authenticator, so my face ID to this newly created user. And like you see, it now asks me that do I want to use my face ID when I create this account and I will tap continue. And yes, we have a new user account now. So what happens next is that I will copy this. So I have a new user name and refresh the page. Next time when I come to this same web application, I just type in the username and tap login. And again, I'm asked that do I want to sign in and use my face ID. And when I tap continue, I'm in the wallet application. We have no new connections yet, so let's meet Faber. I have visual studio code here open and there I have written this kind of simple YAML definition that defines what kind of messages I want to send to the other end when I receive a new pair-wise connection. And actually this spot is then started in the bash script. You don't probably see the text so clearly, but it doesn't matter. But anyway, this bash script uses this CLI tool to launch this bot. So that is what is happening here when I run the script. So probably if I just type in here something like run. So what happened here is that the CLI tool that I'm operating here in the local host computer connects to the cloud agent that we have allocated already before in the cloud for this Faber organization. And it commands the cloud agent to create an invitation to it and then we print the QR code there in the terminal. And this is quite neat because when you have the cloud installation of agency available, you can run this kind of stuff in your local host because of the GRPC API. You don't need tools like ngrok or so forth. So you don't have to expose an HTTP endpoint to the local host. So it's really convenient to test with the wallet application. So I have enjoyed that. But now Alice connects with Faber here. And instantly when we get a new connection, it opens the connection view here in the web wallet view and sends a bunch of messages to Alice. So this is the doing of the chatbot that we are running here in our local host computer. It sends a bunch of basic messages that OK, congratulations on your graduation and so forth. And then it sends a credential offer. And here when we tap accept, we hopefully receive the credential in our wallet. And we can see it here. I apologize that the layout is not as nice at the bifold wallet, but we are back-end coders. So that's it. Then when we have the decree credential, we can verify it. So let's start the ACME bot. And actually same thing happens here. So we just add the new connection. And when we do that, we get a bunch of new messages. And instead of issuing a credential, we get a proof request. And sorry about that. Yeah, layout missing, no. Yeah, so the ACME is asking from us the decree attribute from the credential. And actually our wallet application knows that, OK, this proof is provable. We actually do have a credential that can fulfill this proof request. And when we tap accept, the chatbot gets the values and says that, OK, the proof request goes through. And we have a valid decree from FIPER College. And we are on board at ACME Bank. And as I said, all of this demo stuff can be found in one of our repositories. So we provide you the links later on, but there are detailed instructions on how to run this same stuff in your local host. But now Harry will continue with the technical. How we did it this all. Yeah, sure. First I must find our presentation. There it is. Yep. All right. Thank you for Laura's excellent demo. Maybe just a couple of things before I go to these architectural entities and stuff like that. For example, you saw the web wallet there during our history. We have had native agent, but we have thrown it away. So it's like an example that we have taken different roads during our study. So here is simplified deployment diagram and a little bit more background. All the listed selected technologies, which are in the right side, they comes from our pragmatic approach that we have tried to build the simple and maintainable and also performant solution. Because if you think that we have bank security, it's like, yeah, it's clear. But there was something that triggered us to concentrate these things during our research. And we also wanted to have something out of the box. And FIDO was one of those. But yeah, during the project start, we did try to be orthodox in the SSI and DID principles. And we had those all agent types and stuff like that. Then we started to ask questions. And this is the current solution what you are seeing here. So in the actual deployment diagram, you can see that it's microservice-based. We more concentrate to deployment stuff. And it uses like internal security and ecosystem for the FIDO-based authenticators and authorization. It's done with shot tokens. All these services communicate with except the web wallet, CRPC and TLS pipes. Ordinary stuff. About the web wallet and GraphQL, there is this wall server or service. And it's like it's doing something which make web wallet life easier. That it doesn't have to handle all the verified credentials in same level that you should have otherwise. We have own API there. We don't dive in that very carefully. But that's actually its purpose. We have a little bit started to put different data to different places. What is in the SDK. And before I mentioned hybrid lecture and Indian areas, a little bit that yellow box, which is the agency. It's built three parts. Left first is the FIDO2 authentication server. You could take it actually out of the box. We are the relying party. But we have written it using the dual apps libraries. It was very straightforward thing to do. And then I also mentioned the vault, which is like doing the verified credentials for the web wallet. And in the middle there is the like, I could say, whole thing. We run there our areas protocol state machines. That is our core component. It also handles all the multi-tenancy issues and stuff like that. And as I said, all of these are communicating through the CRPC pipes and TLS. And also it doesn't mean that it has to be the internal setup. But in Laura's demo, the communication actually really happened to this machine and our AWS installation where the agency is running. Yeah, maybe a little bit about the core component. We started totally writing it in the lib. I don't say hybrid lecture in the SDK because we didn't take all. But we took that one library. And we, for example, write our own wrapper for the goal. And lately we have, actually, we started to follow the areas, RFCs, those documents quite early. And now lately when we are starting to approach the AIP 2.0, we took something from the areas go framework. But it wasn't so easy because it's framework. It's so opionated. And we are also very opionated. We have our own way to handle state machines and many, many other stuff in the transport layers. So it wasn't happy merits at all. About the rest of the technologies, Laura already said that we have Docker and Docker images. They are in public registry. They are available for everybody. And you can measure our performance, not very formally, but if you go to the AATH server and you compare, for example, what our agency do when you run it towards itself. And you watch other figures, what other agency do. You can throw your own conclusions, what happens there. And yeah, we have tried to build everything with minimal dependencies as well. And maybe a little bit about the goal. Because we selected for this project. And it has been changing during the project as well. But it's very good for distributed computing. Yeah, maybe before we go to the next slide, I started to explain why we did select the Fido to tuning the fonts here. Sorry. But this actual diagram, it's taken from, or stolen from, Arius, RFC, I think it's cross domain communication. And it's there quite many places. But we think that it's very important diagram. Because we also think that identity domain model, identity domain concept is something that you should understand and you should think about. And this diagram explains that currently Arius has many types of agents and they have many types of roles. And Bob and Alice has almost similar setups. Bob has a little bit more edge agents and also some dedicated cloud agents. But we tried this as well. But I'm going to the point where I say that why we didn't take this approach. If you see what happens when Alice sent message back to Bob and Bob's document in this pairwise connection had this kind of road keys, that's the way how it goes. And we don't think, at least it's at very much complexity to stuff. And if we now think that how we have defined that for ourselves at least, we also think that identity domain is something you must have. That that's the mapping you have from the, could say, analog for world entities like organization, persons, whatever legal entities to this digital world. But we think that all of those identity domain entities have one-on-one mapping to the digital world. And there has been some technical proofs for that as well. You have to have, or if you think about the user experience, it's better that you have 24-7 persons in the network. Let's think about the case that you would have only edge agent. But the edge agent doesn't have mediate or anything else. And other party wants to communicate with that. The end result is pretty bad. And you see many times that did come as compared for email. Email doesn't work like that. At least there is some server in the road that says what is going on and why they cannot reach other end. So we took this approach that we have, we first called it cloud agent, but now we can call it domain agent, identity domain agent even. And there's a couple of reasons that you have to be able to support public deeds, invitation if they are long-lasting ones. And then you have to also maintain those pay-wise connections. And about the routing thing, I have been figuring this out quite long that I really don't understand why they took the static routing approach. Because if you have tens of thousands or millions of these connections, and we like OP have a harder organization, and our setup is changing, we need other mediators and stuff like that. We have to update all the documents. But then during this research work and everything, of course we tried to find other technologies, then we did find FIDO 2. And when we studied it and implemented something, we did learn that it's almost one-on-one what we did have with the DIT exchange when its agent is making pairways to cloud agent. Only that difference that these FIDO 2 authenticators, they are passive device, so they don't need the cloud agent's public keys. They give their own. And it's proven to pretty good approach. And it doesn't exclude native clients at all. Actually they suited that for well. And of course this year some good news came around that this is open source conference, but those big vendors, they have lots of influence. So they already solved for us the case that you lose your authenticators, all of them. And what happens? You can get to access your identity agent in our system now. Maybe I've wrapped up my part. We have open sourced all the software. It wasn't a little job in the bank. It actually was no enormous job. But all the repos are public. And you can, for example, cherry pick whatever you want from there. Because we use the multi-repo model, which isn't very actually good for the go at the moment. Go lang, which has changed a lot in the last three years. We might do something different. But our solution is well documented. There is lots of samples and all the docker images are public in the registry. And as I said, public batteries are included. So there is comprehensive tools for CLI and other which can be used to start everything up. Yeah, that was my part. Thank you. Yeah, OK. Then a couple of words about our future before our time runs out. So what next? We would like to think that Fendi agency is a platform that application developers can take and start building the credential utilizing applications already now and not worry too much about the technology, the dirty technology, like underneath. But to keep the API quite stable and so that the applications can peacefully concentrate to the real things, to the real problems. And for that, we intend to keep the API quite stable. But on the other hand, to explore more about the different credential technologies because we know that Indie has its problems and probably we want to go towards to the ledgerless solutions. We have started working already towards the other technologies and doing the did resolving things that were totally missing from the first version. So these are the ARP2.0, W3C credentials and PBS plus signatures. And the did web method is probably something that we will concentrate in the near future. Of course, we will also do some research in other areas that may or may not result into the code additions to the Fendi agency. So we know that there are happening a lot in those dark sectors that do not believe in DITCOM as we do. So for instance in Finland we have this digital agency doing this wallet project that is based on this SIOP extension for OIDC. So that is something that we are going to look into. Also this door network and did onion stuff is really something that we think that is a good match to this technology. So we want to get into that more. The first pilot cases, we are still waiting from the business for them. But we of course realize that when we get our hands dirty with the actual use cases, there will be needs that we need to implement more features and so forth to the Fendi agency. And that also goes hand in hand with the performance and scalability needs. So that is something that we want to investigate more. Actually we know that with ACAPI there is this low generator tool. We have a little bit of like tried it out with the Fendi agency as well and that kind of work we want to continue in the future as well. So that was our presentation. I hope that you now know a little bit more about Fendi agency what it is. I recommend you to find out more. So join the fun. Go to a website with the documentation blog post videos and most importantly try it out. Install it to your local host and give us feedback what is good, what is bad. And you can email us. You can find us in Twitter and in LinkedIn. Thanks. Do we have any time for questions? Any questions? Yes, please. Unfortunately we don't have as Laura mentioned. We are the research department and actually last year the other guys they really tried to find something. They are maybe a couple of cases. There is this what is the document of attorney. You give the crides to do. Someone else can do. Yeah, actually exactly that. Yeah, that is something that is from table to table. And then there is also interesting thing that you could renew your, all the banks has those old, they call it strong authentication tools that you could use this technology to renew your, I use authenticators but they are old authenticators. Yeah, we have been doing some like playing around with ideas exactly like this chatbot thing that we showed that it would be a good thing to use like when negotiating alone or like in the insurance cases when you need to like send documents to several parties and so forth but quite honestly we have been struggling to explain this technology to the business. Yeah, I actually tried out yesterday when you announced it and when I connected it with the wallet application so there was something that busy wallet. I think that it's waiting for trust being or something like that that it didn't get the connection but in our end it worked so I need to dig into that work. Yeah, but basically yeah. There was question there at the back row. Yeah, it was indeed missing. The timeline is also crucial here because we started much earlier than those guys. Or at least we found it. It's true about half a year because we were building everything before the areas was existing and in the summer we found out those specs and we started to follow them but yeah, that's true that very lately we started to take parts from the areas go framework but actually before that I have read the code all the time I have tried to keep myself like in the day that what is going on but what could might be good example we have of course state machines for the protocols you have to have those and those guys have made their version and there is also transport layers and they are totally different and I don't think that this public knowledge but frameworks are usually opinionated it's like we give the way how we call you back but the libraries are like that you can call us and we do the thing and our approach is this library approach and it was very difficult to use the code framework but that is true I wouldn't use it in production but most importantly I wouldn't use in the production that's my reason but I think our code is quite good quality so it's not dependent on that My concern is actually the lecture the indie lecture there is something we have found during the tests and maybe there has been all the time some performances and if we go that road I don't like did comma I think that there is flaws in it and they try to fix something in version 2 but like an attack man in the middle attack I don't know how well it's handled but it's so long discussion don't go that road yeah please they are in the cloud but we have built a system like that that you could, because this agency you could remove your wallet totally and no trace is there and switch to other agency yeah that's what we have used so you have that feature yeah we haven't concentrated too much but like the background of our heads yeah that's true but it was implemented at least and we tried it it was like this has been so long road because we weren't sure that we will throw H8's away this was that point we thought that we have to have that feature so you could, how I explained this shortly we run actually H8's and cloud 8's and in cloud together and the reason was that you could took the H8's wallet out of the cloud and give it some orderly setup and we tried that yeah actually that that's the point that you we are not mediator or anything like that that you don't access the wallet at the API level like if you think that did controller it uses our API and there was this should I use the everything you see here see here it's like done in our API and our if someone wants to call it proper they can but then when you start to communicate outside we are not support like that you would use us as cloud agent and you would have other H8's agent if you asking that we are like supporting that case that this is your domain agent you are contacting and making those did compare races some other entities and they can have roads but it's like a it's a little bit different I think that it's not following the same principles like for example ACAPI or by fault that we saw yesterday that was having the mediator in the cloud and so forth so Harry has written in the code wrapper this kind of mechanism that you can replace like the you don't actually send the request to the ledger but we can store them in a file or a memory or what was the third one immu.db whatever data storage can be there and there is one hack only that in the STG it accepts that the wallet handle can be minus one and then it doesn't deal with it because you know that the API isn't perfect in the indie so that allowed us that the second level code can still think that it talks to the indie STG but data storage can be whatever so what we're trying to do is yeah yeah yeah yeah yeah yeah yeah yeah and actually it started for the help the developers because it was so complicated to set up the always the ledger and actually if you go like to our startup scripts and started the agency in your local host it just uses the file ledger by default so you don't have to set up any ledger not hacking is right here maybe reverse engineering because I just want to make sure because there is only two functions that take this is very technical, sorry take the connection handle and wallet handle and one of them it actually doesn't do anything I checked the Rust code it doesn't do anything for the wallet handle and other does but it does it only certain scenarios and so it was safe to send the minus one for the wallet handle mainly the ledger yeah good to answer so but you have to start somewhere and like I think that the instance that we have brought this interoperability tests and so forth like in the picture it has helped us a lot like doing the testing out the protocols and so forth so you have to have something and I think that none of us will know knows now which will be the winning horse in the credential race but you have to have something to build like on top of okay maybe is this last question but yeah okay I have to check it out okay thank you